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The  research  described  in  this  thesis  provides  a  set 
of  benchmarks  which  would  provide  flight  control  software 
personnel  with  the  ability  to  evaluate  various  Ada  compil¬ 
ers,  the  compiler's  run-time  systems,  and  various  MIL-STD- 
1 7  5  0  A  processors  for  suitability  for  flight  control  soft¬ 
ware.  The  benchmarks  developed  during  this  thesis  are 
designed  to  help  the  flight  control  and  compiler  perfor¬ 
mance  evaluation  communities. 

I  would  like  to  thank  Lieutenants  Marc  Pitarys  and  Bob 
Marmelstein  for  their  help  in  getting  access  to  the  Ada  com¬ 
pilers  and  1750A  processors  as  well  as  furnishing  instruc¬ 
tions  and  manuals  on  their  use.  I  would  also  like  to  thank 
Captain  Dan  Joyce  and  Major  Roger  Kontak,  fellow  students, 
for  their  encouragement  and  help  while  we  spent  many  hours 
in  the  Avionics  Laboratory. 


Accession  For 

NT1S  CP.  Ail 
DTIC  TAB 
Unfumaja: 


By 

D  t  lit  r  ‘  L.  :t 


Table  of  Contents 


Preface 


List 

0  f 

Figures  . 

List 

0  f 

Tables  .  . 

List 

0  f 

Ac  ronyms 

Ab  s  t  r  a  c  t 


I.  Introduction  . 

Statement  of  the  Problem  . 

Background  . 

Scope  . 

Limitations  . 

Research  Approach  . 

Research  Gain  . 

Thesis  Organization  . 

II.  Literature  Review  . 

Flight  Control  Software  Domain  . 

Benchmark  Testing  . 

III.  System  Design  . 

Compiler/RTS  Evaluation  Requirements 

Alternative  Evaluation  Systems  . 

System  Overview  . 

Benchmark  Tests  . 

Control  Laws  . 

Gain  Table  Interpolation  . 

Redundancy  Management . 

Test  Selection  . 

IV.  Detailed  Design  . 

Control  Laws . 

Function  . 

Description  . 


Page 
i  i 


v  i 

v  i  i 

v  i  i  i 

1 

1 

1 

4 

5 
5 

J  0 
10 

1  2 

1  2 
1  7 

22 

22 

23 

25 

27 

27 

29 

29 

30 

32 

32 

32 

32 


# 


( 


Gain  Table  Interpolation  .  35 

Function  .  35 

Description  .  35 

Redundancy  Management  .  36 

Test  Procedures  .  37 

V.  Test  Analysis  .  40 

Validation  Method  . 40 

Control  Laws  . 41 

Gain  Table  Interpolation  .  42 

Redundancy  Management  .  43 

Summary  .  44 

VI.  Conclusions  and  Recommendations  .  45 

Achievement  of  Objectives  .  45 

Conclusions  .  47 

Additional  Observations  .  47 

Recommendations  for  Further  Research  .  48 

Appendix  A:  Two  Styles  of  Coding  Control  Laws  .  50 

Appendix  B:  Gain  Table  Interpolation  .  52 

Appendix  C:  Sample  Test  Results  .  54 

Bibliography  .  61 

VITA  .  64 


% 

I 

B 


I 


D 


I 

% 


Cl 


w 


8* 


List  of  Figures 


Figure 


Page 


Dual  Loop  Benchmark 


Global  Coding  Style 


Local  Coding  Style 


Frequency  Compensation  Filter  Gain  Table 


List  of  Tables 


Table 
I . 
II  . 
Ill  . 

IV  . 

V  . 

VI  . 
VII. 

VIII. 


Ada  Constructs  Important  in  Flight  Control 

Functional  Area  Resource  Utilization  . 

Language  Constructs  and  Operands  Used  in 
AFTI/F-16  Flight  Control  Law  Computations 

Results  of  Control  Law  Test  With  Global 
Variables  and  Constants  . 

Results  of  Control  Law  Test  With  Local 
Variables  and  Constants  . 

Gain  Table  Interpolation  . 

LEF  Monitor  With  No  Failures  Detected 
During  Execution  . 

LEF  Monitor  With  Failures  Detected  During 
Execution  . 


ABICS-II 

ACEC 

ACM 

AC  VC 

AFTI 

AFWAL 

ANSI 

AT  F 

DEC 

DFCS 

DOD 

FLCC 

LEF 

LRM 

OF  P 

PIWG 

RTS 

UCCS 

US  AF 


List  o  f  Acronyms 

Ada  Based  Integrated  Control  System  II 
Ada  Compiler  Evaluation  Capability 
Association  for  Computing  Machinery 
Ada  Compiler  Validation  Capability 
Advanced  Fighter  Technology  Integration 
Air  Force  Wright  Aeronautical  Labs 
American  National  Standards  Institute 
Advanced  Tactical  Fighter 
Digital  Equipment  Coroporation 
Digital  Flight  Control  System 
Department  of  Defense 
Flight  Control  Computer 
Leading  Edge  Flap 
Language  Reference  Manual 
Operational  Flight  Program 
Performance  Issues  Working  Group 
Run  Time  System 

University  of  Colorado  at  Colorado  Springs 
United  States  Air  Force 


Abstract 


this  research  characterizes  flight  control  software  in 
terms  of  the  Ada  (TM)  constructs  used  and  of  the  performance 
ch a r a c t e r i s t i c s  that  determine  the  suitability  of  a  partic¬ 
ular  compiler/processor  system  for  flight  control  software. 

A  new  set  of  three  flight  control  software  benchmarks  based 
on  this  characterization  was  evaluated  on  two  MIL- STD- 1  7 50A 
processors  using  two  Ada  compilers.  Results  show  that  com¬ 
piler/processor  combinations  can  be  compared  for  their  abil¬ 
ity  to  implement  flight  control  software  in  execution  speed 
and  memory  size  required.  The  benchmarks  provide  time  and 
space  requirements  for  a  typical  sample  of  flight  control 
software . 


I nt  roduc  t  ion 


I  . 

Statement  o  f  the  P  r ob 1 em 

The  Department  of  Defense  developed  the  Ada  programming 
language  in  the  19  7  0  '  s  to  facilitate  software  development 
in  defense  applications,  primarily  embedded  systems  appli¬ 
cations  (Booch,  1983:3-4).  Flight  control  is  a  specialized 
embedded  system  application  which  controls  an  aircraft  as 
it  travels  through  the  atmosphere.  Future  United  States  Air 
Force  (USAF)  flight  control  software  will  be  implemented  in 
Ada  rather  than  JOVIAL  and  assembly  languages,  the  current 
languages.  However,  no  determination  has  yet  been  made  on 
the  ability  of  the  Ada  language  to  implement  flight  control 
software  efficiently  and  effectively. 

Background 

The  JOVIAL  programming  language  was  developed  in  con¬ 
junction  with  the  development  of  avionics  and  flight  control 
applications.  This  joint  evolution  has  made  JOVIAL  particu¬ 
larly  well  suited  for  flight  control  applications.  Flight 
control  software  has  often  been  a  combination  of  JOVIAL  and 
assembly  languages  (Joslin,  1987). 

Both  the  machine  dependency  of  assembly  languages  and 
the  intermixing  of  JOVIAL  and  assembly  languages,  however, 
make  flight  control  software  hard  to  maintain  and  limit 
the  portability  of  such  software  to  other  flight  control 
systems.  Because  the  Department  of  Defense  (DOD)  developed 


Ada  to  improve  the  maintainability,  reliability,  and  porta¬ 
bility  of  software  (Booch,  1983:3-4),  DOD  policy  now  requires 
that  software  developed  for  major  systems  be  written  in  Ada 
(DOD,  1987). 

The  current  DOD  policy  was  preceded  by  numerous  DOD 
Directives  and  Instructions,  all  of  which  augured  the  latest 
policy  which  requires  the  use  of  Ada  (Witt,  1985:3-4).  In 
accordance  with  these  policies,  the  "Ada  Based  Integrated 
Control  System  II  (ABICS-II),"  the  first  attempt  to  use  Ada 
for  a  major  USAF  weapon  system,  resulted  in  a  majority  of 
the  flight  control  software  for  the  F- 1 5  being  written  in 
Ada  (portions  of  the  software  were  written  in  assembly 
language  to  increase  the  speed  of  execution)  (Landy  and 
others,  1986).  This  software,  containing  a  mixture  of  Ada 
and  assembly  language,  was  tested  in  flight,  identifying  a 
number  of  constructs  of  Ada  (see  Table  I)  as  important  in 
flight  control  applications  (Landy  and  others,  1986:9-2 
to  9-15).  The  ABICS-II  project  was  also  one  of  the  first 
applications  integrating  the  various  on-board  computer 
controlled  systems  (e.g.,  flight  and  fire  control  systems); 
the  trend  today  is  toward  increasing  integration  of  computer 
controlled  systems  on  aircraft  (Joslin,  1987). 

The  ability  of  Ada  to  handle  future  real-time  embedded 
applications  effectively  depends  upon  the  efficiency  of  the 
generated  code,  the  run-time  system  (RTS)  furnished  with 
the  compiler,  and  the  processor  architecture.  In  flight 
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TABLE  I.  Ada  Constructs  Important  in  Flight  Control 
(Landy  and  others,  1986:9-2  to  9-15) 


Fixed  and  Floating  Point  Data  Types 

Subprograms 

Conditional  Control 

Iterative  Control 

Packages 

Generics 

Tasking 

Except  ions 

Im p  1  e me n t a t i o n- d e p e n d e n t  Features  (specifically 
representation  specifications) 

Pragmas 

Low-level  Input/Output 


control  applications,  the  speed  of  execution  of  the  software 


can  not  only  affect  the  performance  of  an  aircraft,  but  even 


be  a  matter  of  life  and  death,  so  the  ability  to  determine 


the  c omp i 1 e r / 1 7 5 OA  processor  which  generates  the  fastest 


Ada  code  can  lead  to  safer  and  better  performing  aircraft. 


Also,  since  contemporary  flight  control  computers  are  based 


on  M I L- S TD-  1 7  5 0 A  processors  limited  to  64K  or  1 2  8  K  bytes  of 


memory,  a  flight  control  compiler  must  also  be  space  effi¬ 


cient.  The  memory  limit  is  due  to  the  addressing  limita¬ 


tions  of  MIL-STD- i 750A  (DOD,  1980) 


Current  compiler  assessment  capabilities  are  divided 


into  validation  criteria  and  evaluation  measurements.  Val¬ 


idation  CKitZKia  enumerate  the  features  of  a  language  which 


a  compiler  mut>t  implement  to  be  used  for  software  development 


for  the  validating  agency.  The  validation  criteria  for  the 


DOD  are  contained  in  a  series  of  tests  called  the  Ada  Compiler 


Validation  Capability  ( A  C  V  C  )  .  This  test  suite  determines  if 
a  target  compiler  conforms  with  AN S I /M I L- S TD- 1  8  1  5 A ,  Ada  Pro¬ 


gramming  Language  Reference  Manual  (LRM)  (DOD,  1983),  in 
which  case  it  is  considered  validated .  The  ACVC  does  not 
provide  data  with  which  to  compare  compilers  or  test  imple¬ 
mentation  dependent  features. 

Evaluation  measurement*  determine  the  efa&iciency  with 
which  a  compiler  implements  a  language  feature  or  features. 

The  efficiency  of  a  compiler  can  be  measured  in  the  speed 
(either  compilation  or  execution)  or  the  size  of  the  machine 
code  it  generates.  Two  of  the  test  suites  used  to  evaluate 
Ada  compilers  are  the  prototype  Ada  Compiler  Evaluation 
Capability  (ACEC)  (Hook  and  others,  1985)  and  the  Performance 
Issues  Working  Group  (PIWG)  of  the  Association  for  Computing 
Machinery  (ACM)  benchmarks  (Squire,  1986).  The  ability  of  the 
ACEC,  PIWG,  and  other  test  suites  to  evaluate  compiler  per¬ 
formance  for  flight  control  applications  has  not  been  studied. 

Scope 

This  research  developed  tests  to  evaluate  the  code  size 
and  execution  speed  of  Ada  code  used  to  implement  flight 
control  software.  The  goal  of  the  research  was  to  obtain  a 
comparative  evaluation  of  Ada  compilers  for  flight  control 
software.  The  speed  of  execution  of  the  Ada  code  was  chosen 
as  one  evaluation  criterion  because  the  real-time  embedded 
nature  of  flight  control  software  requires  operations  to  be 
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executed  within  a  specified  time  frame  for  a  particular 
flight  control  application.  Execution  speeds  within  this 
time  frame  would  insure  suitability  of  a  tested  compiler 
and  processor  for  that  application.  The  code  size  gener¬ 
ated  was  evaluated  as  a  second  criterion  because  the  lim¬ 
ited  memory  available  for  flight  control  software  using 
1750A  processors  requires  the  code  to  be  as  space  efficient 
as  possible.  A  smaller  code  size  will  allow  an  application 
to  include  more  finely  detailed  control  law  computations 
and  better  redundancy  management  schemes,  resulting  in  more 
effective  flight  control  software. 

Limitat ions 

This  research  did  not  attempt  to  obtain  an  absolute 
evaluation  of  compilers.  An  absolute  evaluation  would  need 
to  test  all  the  language  features  that  a  compiler  implements 
Since  flight  control  software  does  not  use  all  features  of 
Ada,  an  absolute  comparison  is  not  necessary.  For  example, 
text  input/output  is  not  necessary  for  flight  control  soft¬ 
ware. 

Research  Approach 

The  first  step  of  this  research  was  a  definitional  phase 
to  characterize  flight  control  software  in  terms  of  Ada  con¬ 
structs  used,  algorithms  employed,  and  flight  control  func¬ 


tions  addressed. 


Next,  Ada  programs  which  embodied  each 


feature  of  the  definition  were  coded,  tested,  and  evaluated 
in  an  incremental  fashion,  with  one  program  being  evaluated 
before  coding  on  the  next  was  begun.  This  incremental  ap¬ 
proach  allowed  the  research  to  be  refined  as  it  proceeded: 
after  each  evaluation,  correctional  feedback  from  the  spon¬ 
sor  could  be  integrated  and  all  aspects  of  the  research 
could  be  judged  for  their  suitability  to  the  final  goal. 
Suitability  of  a  test  was  analyzed  by  surveying  experts  in 
the  fields  of  flight  control  software,  flight  control  mech¬ 
anization,  and  compiler  benchmarking  on  whether  the  test  as 
designed  would  provide  the  results  needed  to  answer  the  the¬ 
sis  problem.  This  approach  limited  the  number  of  tests  de¬ 
veloped;  however,  it  reduced  useless  activity. 

First,  then,  current  flight  control  software  was  ex¬ 
amined  to  determine  its  domain  and  the  operations  which  were 
the  critical  cost  drivers  in  the  code.  The  domain  of  flight 
control  software  is  defined  as  the  language  constructs  used, 
the  number  and  types  of  constants  or  variables  employed, 
limits  in  the  range  of  the  variables  and  constants,  and  the 
control  structure  used  in  the  software.  The  flight  control 
software  examined  was  the  Integrated  Flight  and  Fire  Control 
Software,  Ada  Language  (University  of  Colorado  at  Colorado 
Springs  (UCCS),  1986  )  written  for  the  F-  I  5 ,  the  Advanced 
Fighter  Technology  Integration  (AFTI )  /  F—  16  Development  and 
Integration  Program,  DFCS  Phase  Final  Technical  Report 
(Henley  and  others,  1984),  and  the  software  used  in  the 
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ABICS-II  (Landy  and  others,  1986)  project.  This  examination 
allowed  the  domain  of  flight  control  software  to  be  deter¬ 
mined  and  Ada  code  developed  to  test  different  aspects  of 
this  doma  i  n . 

The  ABICS-II  software  was  chosen  because  it  was  the 
first,  and  to  this  date  only,  use  of  Ada  code  for  actual 
implementation  of  flight  control  software  (Voelcker,  1987: 

44).  The  UCCS  software  was  chosen  because  it  offered 
another  approach  which  could  have  been  used,  although  it  was 
never  implemented,  to  program  flight  control  software  in  Ada 
for  the  F- 1 5 .  As  the  AFTI/F-16  design  code  (as  the  name 
implies)  is  in  the  forefront  of  integrating  new  technologies 
into  current  and  future  aircraft  (Voelcker,  1987:  48),  the 
software  developed  was  based  on  the  AFTI/F-16  flight  control 
design.  An  analysis  based  on  manually  counting  specific 
types  of  statements  (add,  multiply,  assignment,  etc.)  pro¬ 
vided  a  definition  from  which  tests  could  be  developed  which 
would  measure  the  ability  of  an  implementation  of  Ada  to  im¬ 
plement  flight  control  software  effectively  and  efficiently. 

In  addition  to  developing  tests,  the  ACEC,  PIWG,  and 
other  available  benchmark  test  suites  were  examined  to  deter¬ 
mine  if  any  of  their  tests  were  suitable  for  use  in  evaluat¬ 
ing  compilers  for  flight  control  applications  (as  defined  by 
the  previous  computations).  This  examination  was  accomplished 
by  comparing  the  constructs  of  Ada  tested  by  the  benchmarks 
and  determining  if  the  same  constructs  were  present  in  a 


a  usage  similar  Co  their  usage  in  flight  control  software. 

Any  tests  which  contained  Ada  constructs  in  the  same  fre¬ 
quency  and  used  those  constructs  in  the  same  manner  as 
flight  control  software,  or  tests  which  were  able  to  be 
modified  to  do  so,  were  incorporated  into  the  research 
project  test  suite.  Tests  were  designed  for  language  fea¬ 
tures  for  which  no  suitable  tests  could  be  found  which  sim¬ 
ulated  the  flight  control  domain. 

All  benchmark  tests  that  could  be  run  on  a  DEC  VAX- 1  I / 
780  or  a  DEC  VAX-1  1/  7  8  5  under  the  VMS  operating  system  were 
assumed  to  execute  properly,  based  on  the  facts  that  the  DEC 
VMS  Ada  compilers  are  validated  and  that  each  benchmark  had 
been  previously  executed  on  other  m a c h i n e / c om p i 1 e r  combina¬ 
tions  with  no  errors.  Proper  execution  was  defined  as  cor¬ 
rect  results  being  achieved  for  numeric  calculations  and  the 
correct  path  chosen  in  conditional  statements  based  on  the 
conditions  at  the  time  the  statement  was  executed.  The  tests 
were  then  executed  on  each  of  two  compilers  and  two  I750A 
processors.  The  compilers  and  processors  were  chosen  be¬ 
cause  they  are  representative  of  the  seven  validated  1750A 
Ada  compilers  and  twelve  (as  far  as  is  known)  1750A  pro¬ 
cessors  available  (Siegert,  1987;  Pitarys,  1987).  Addition¬ 
ally,  the  chosen  compilers  and  processors  are  currently  being 
used  in  DOD  evaluation  tests,  funded  research,  or  the  devel¬ 
opment  of  current  and  future  projects  (Siegert,  1987; 

Pitarys,  1987).  Each  test  was  run  a  number  of  times  on  the 
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same  processor/compiler  combination.  Statistical  analysis 
of  the  execution  times  was  used  to  determine  if  there  were 
any  significant  differences  between  runs  on  the  same  proces¬ 
sor/compiler  combination  or  between  p r o c e s s o r / c omp i 1 e r  com¬ 
binations.  The  results  compared  the  compilers  based  on  test 
execution  speed  and  size  of  code  generation. 

No  attempt  was  made  to  make  a  single  rating  of  compilers 
based  on  all  of  the  tests.  Such  a  composite  rating  was  not 
done  because  each  benchmark  typically  measures  a  limited  fea¬ 
ture  (  s  )  within  a  language.  The  importance  of  a  particular 
feature  is  dependent  on  the  application  for  which  it  will  be 
used.  Each  application  manager  will  need  to  make  the  deter¬ 
mination  of  what,  if  any,  tradeoffs  are  acceptable,  based  on 
the  test  results,  and  choose  the  appropriate  compiler/proces- 
sor  combination. 

The  research  was  finished  when  all  of  the  benchmarks 
were  run,  either  successfully  or  unsuccessfully,  on  each  of 
the  I750A  processor/coupiler  combinations  and  the  results 
analyzed  to  determine  the  suitability  of  the  tests  in  eval¬ 
uating  the  various  combinations  for  implementing  flight  con¬ 
trol  software.  The  success  of  the  tests  in  measuring  the 
ability  of  Ada  to  implement  flight  control  software  was  val¬ 


idated  by  discussing  the  design  and  implementation  specifics 
with  experts  in  the  fields  of  flight  control  and  compiler 
benchmarking. 


Research  Gain 


This  research  provided  the  first  series  of  tests  that 
allows  flight  control  researchers  to  compare,  based  on  the 
speed  of  execution  and  the  code  size  generated,  the  effec¬ 
tiveness  of  various  Ada  comp  i  1 e r s / RTS  for  flight  control 
applications.  Also,  this  was  the  first  known  attempt  to 
identify  and  characterize  the  critical  cost  drivers  in 
flight  control  software. 


Thesis  Organizat ion 

Chapter  II  presents  work  that  has  been  done  previously 
on  Ada  compiler  evaluation  and  on  flight  control  character¬ 
ization.  The  domain  of  flight  control  applications  is  de¬ 
termined  based  on  examples  from  the  literature.  The  eval¬ 
uation  of  Ada  compilers  for  general  applications  and  real¬ 
time  systems  is  examined  to  understand  the  process  of  bench¬ 
marking  and  to  look  for  tests  which  may  be  suitable  for 
flight  control. 

Chapter  III  explains  the  system  designed  to  evaluate 
Ada  compilers  for  flight  control  applications.  The  method 
by  which  Ada  constructs  were  chosen  for  evaluation  and  how 
the  constructs  were  measured  is  explained. 

Chapter  IV  provides  a  detailed  explanation  of  each 
benchmark.  The  development  of  each  benchmark  is  explained 
and  the  method  used  to  measure  the  execution  speed  described 


Chapter  V  describes  validation  of  the  designed  tests. 


Chapter  VI  explains  the  conclusions  obtained  from  the 
research.  The  problems  encountered  in  the  research  effort 
possible  future  research,  and  the  benefits  gained  in  the 


1 1 .  Literature  Review 

To  determine  if  Ada  can  effectively  implement  flight 
control  software,  the  problem  defined  in  Chapter  1,  two 
areas  must  be  addressed.  Initially,  the  domain  of  flight 
control  software  must  be  defined.  Consequently,  this  chap¬ 
ter  surveys  the  existing  sources  of  flight  control  software 
to  characterize  it.  Secondly,  the  capability  of  Ada  to  pro¬ 
duce  efficient  and  effective  code  in  this  domain  must  be 
evaluated.  So  this  chapter  examines  the  existing  research 
that  has  been  conducted  in  Ada  compiler  evaluation  for  flight 
c o n t r o 1  - s e n s i t  i v e  features. 

F 1  i gh  t  Control  Software  Domain 

Recall  from  Chapter  I  that  the  domain  of  flight  control 
software  is  defined  as  the  flight  control  functions  imple¬ 
mented,  language  constructs  used,  and  algorithms  employed  in 
the  software.  The  first  step  in  determining  the  domain  of 
flight  control  software  was  to  determine  which  aircraft 
would  be  included  in  the  domain  definition.  Calls  to  all 
the  major  contractors  and  the  project  offices  for  the  X-29 
and  the  advanced  tactical  fighter  (ATF)  aircraft  revealed 
these  projects  were  still  in  the  design  phase  and  could 
not  provide  data  useable  for  the  domain  definition.  Data 
was  obtained  for  the  ABICS-II  F-  1  5  aircraft  ( Landy  and 
others,  1986),  the  IFFC  F  —  1  5  flight  control  law  study  (UCCS, 
1986),  and  the  AFTI/F-16  project  (Henley  and  others,  1984). 


Examination  of  documents  from  the  preceding  studies 


produced  the  following  functional  area  decomposition: 


1.  Executive.  The  executive  is  designed  to 
control  and  schedule  the  execution  of  the 
other  tasks  in  flight  control  software.  The 
executive  may  include  checks  on  certain  in¬ 
terrupts  to  insure  completion  of  tasks  (Ram- 
age  and  others,  1981:21-22;  Landy  and  others, 
1986:4-2  to  4-5). 

2.  Redundancy  Management  or  Select ion/Mon- 
itoring  of  Inputs/Outputs.  This  portion  of 
the  software  accepts  inputs  from  aircraft 
sensors  and  checks  them  for  validity  by 
comparison  to  other  sensor  inputs  and  for 
reasonableness  based  on  predefined  limits. 

The  inputs  are  forwarded  to  the  computational 
phase  upon  acceptance.  The  outputs  follow 
the  same  validity  checking  but  flow  from  the 
computational  phase  to  the  control  surfaces 
of  the  aircraft  (Ramage  and  others,  1981: 

22-24;  Landy  and  others,  1986:4-8  to  4-9). 

3.  Control  Laws.  The  mathematical  calcu¬ 
lations  which  solve  flight  dynamics  equations 
are  computed  in  this  portion  of  the  software. 

The  inputs  from  sensors,  pilot  selections, 
and  possibly  previous  inputs  or  outputs  are 
used  to  arrive  at  commands  for  aircraft 
control  surfaces  (Ramage  and  others,  1981: 

24-25;  Landy  and  others,  1986:4-5  to  4-8). 

4.  Pilot  Interface.  This  portion  of  the 
software  handles  the  input  and  output  of 
data  to  displays  in  the  aircraft  cockpit. 

5.  Others.  Additional  modules  of  the  flight 
control  software  include  system  tests,  startup 
and  restart  routines,  and  failure  management 
modules. 

An  examination  of  the  time  and  space  used  by  each  of  these 
functional  areas  determines  which  functional  areas  are  crit 
ical  time  and  space  cost  drivers.  Table  II  provides  a  sam¬ 
ple  analysis  of  such  functional  area  resource  usage. 
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The  0.0  percentages  recorded  in  time  a  sage  reflect  the 
fact  that  the  system  monitor  and  startup/restart  functions 
are  not  active  during  flight  but  operate  only  during  ground 
operations.  The  spare  time  recorded  reflects  time  which  is 
used  to  execute  non-critical  functions.  The  spare  memory 
recorded  reflects  unused  memory  locations.  The  figures  in 
Table  II  are  for  the  AFTI/F-16  aircraft:  the  figures  for  the 
ABICS-II  F- I  5  aircraft  are  significantly  different,  although 
the  distribution  of  resources  among  the  functional  areas  is 
similar  with  control  law  and  redundancy  management  functions 
the  critical  cost  drivers,  using  29  and  31  percent  of  the  time 
and  13  and  15  percent  of  the  memory  respectively  (Landy  and 
others,  1986:4-16,  8-6). 


Table  II.  Functional  Area  Resource  Utilization 
(Yousey  and  others,  1984:3-2) 


Functional  Area 

Time 

Memory 

Execut  ive 

6 . 0 

2  .  7 

Redundancy  Management 

43.6 

2  3.3 

Control  Laws 

30.0 

34  .  0 

Pilot  Interface 

12.0 

5  .  4 

System  Monitor 

0 . 0 

17.7 

Startup/Restart 

0 . 0 

2  .  2 

S  p  are 

8  .  4 

15.7 

Total 

100.0 

10  0.0 
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The  next  step  in  defining  the  domain  of  flight  control 
software  was  identifying  from  the  three  p r o j e c t s / s t u d  i  e s 
previously  mentioned  the  Ada  language  constructs  used  to 
implement  flight  control  functions. 

The  ABICS-II  study  identifies  key  Ada  constructs  per¬ 
tinent  to  flight  control  (see  Table  I,  page  3)  and  the 
interaction  of  these  constructs  based  on  actual  experience 
in  using  Ada  to  implement  flight  control  software  for  the 
F- 1 5 ,  the  first  such  use  of  Ada.  Floating  point  arithmetic 
was  used  for  computing  the  control  laws  and  was  implemented 
in  software  rather  than  hardware  (Landy  and  others,  1986: 
9-10  to  9-11).  The  executive,  control  laws,  and  a  built-in 
test  were  coded  in  Ada  (Landy  and  others,  1986:2-2).  Inter¬ 
rupt  handling,  input/output  (I/O),  some  logic  and  math  func¬ 
tions,  and  redundancy  management  were  coded  in  assembly 
language  (Sargent,  1987).  Iterative  control,  conditional 
control,  tasking,  exceptions,  and  the  capability  to  inter¬ 
face  with  various  hardware  components  were  stressed  as 
important  Ada  constructs  in  flight  control  applications 
(Landy  and  others,  1986:9-3  to  9-14).  Additional  Ada  con¬ 
structs  found  to  be  useful  were  packages,  functions,  and 
procedures:  these  additional  Ada  constructs  allowed  programs 
to  be  decomposed  into  modules,  speeded  development,  and 
allowed  quick  adapting  of  changes  because  of  the  isolation 
of  the  effect  of  a  change  to  a  small  module  set  (Landy  and 
others,  1986:9-3  to  9-5). 


The  IFFC  Software  (UCCS,  1986)  provides  an  alternative 
method  of  implementing  flight  control  software  in  Ada  for 
the  F-15.  The  IFFC  software  has  never  been  used  in  flight 
and  includes  no  assembly  language  routines.  The  IFFC  soft¬ 
ware  contains  no  exception  handling  or  tasking,  nor  does  it 
interface  with  the  underlying  hardware.  Otherwise,  it  con¬ 
tains  the  same  Ada  constructs  used  in  similar  frequencies  as 
the  ABICS-II  software  (UCCS,  1986). 

The  AFTI/F-16  report  (Henley  and  others,  1984)  contains 
the  software  design  of  the  AFri/F-16  digital  flight  control 
system.  The  design  documentation  includes  psuedocode  and 
detailed  control  law  computation  algorithms.  Using  fixed 
point  arithmetic  for  control  law  computation  (Ramage  and 
others,  1981:5-6),  the  AFTI/F-16  flight  control  software 
was  coded  in  assembly  language.  However,  the  pseduo  code 
allows  the  algorithms  to  be  analyzed  in  a  higher  order 
language.  The  psuedocode  and  control  law  computations 
algorithms  reveal  that  the  same  types  of  Ada  constructs 
used  in  similar  frequencies  are  needed  for  the  AFTI/F-16 
as  are  needed  for  the  ABICS-II  and  IFFC  flight  control 
implementations  (Henley  and  others,  1986). 

The  final  step  in  defining  the  domain  of  flight  control 
software  is  to  determine  the  algorithms  used  to  implement 
flight  control  software.  An  examination  of  the  three  flight 
control  software  d o c ume n t s / s t u d  i  e s  previously  listed  show 
that  the  specific  algorithms  used  vary  from  aircraft  to 


aircraft  for  flight  control  software. 


The  differing  algo¬ 


rithms  are  caused  by  the  varying  number  and  type  of  control 
surfaces,  sensors,  and  the  redundancy  built  into  the  hardware 
of  the  aircraft.  However,  the  various  algorithms  include 
the  same  types  of  operations  in  similar  frequencies  which 
include  evaluating  inputs  and  outputs  for  consistency,  com¬ 
puting  similar  flight  dynamics  equations,  and  interpolating 
between  data  points  (Yousey  and  others,  1984:4-14,  3-64; 

Henley  and  others,  1984:13-1  to  13-192;  Landy  and  others, 
1986:4-7  to  4-9). 

Benchmark  Test  i  n  g 

The  evaluation  of  compilers  through  the  use  of  bench¬ 
mark  tests  has  been  used  often  in  the  past  (Bennell,  1975: 
vii).  Although,  the  use  of  benchmarks  for  real-time  systems 
using  Ada  has  only  recently  been  started,  numerous  bench¬ 
mark  programs  exist  in  the  public  domain  for  Ada.  The  pro¬ 
to  type  Ada  Compiler  Evaluation  Capability  (ACEC)  (Hook  and 
others,  1985)  is  a  series  of  benchmark  tests,  each  of  which 
evaluates  an  individual  Ada  language  feature  or  a  combina¬ 
tion  of  Ada  language  features.  The  prototype  ACEC,  developed 
for  supermini  or  larger  computers  from  tests  available  in  the 
public  domain  (Hook  and  others,  1985:1),  also  includes  a  sup¬ 
port  system  which  allows  timing  statistics  to  be  gathered. 

The  tests  in  the  prototype  ACEC  are  divided  into  two 
main  categories.  The  n  0 ’ima  ti-V  d  category  contains  tests  of 
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features  required  to  be  part  of  the  Ada  language  by  the  LRM. 
The  optional  category  includes  tests  of  Ada  constructs  not 
required  by  the  LRM.  Both  categories  contain  tests  of  some 
of  the  Ada  constructs  pertinent  to  flight  control  as  described 
in  the  previous  section. 

Some  ACEC  tests  rely  on  a  control  and  a  test  version  of 
each  program.  The  cost  of  implementing  a  particular  Ada 
feature  is  determined  by  the  difference  in  the  time  required 
to  execute  the  two  differing  versions  of  the  test.  The  <6 y  n- 
t  he.  t  ic  tests  in  the  prototype  ACEC  rely  on  only  a  single  test 
which  is  executed  on  two  systems,  with  the  difference  in 
execution  speed  used  for  comparison  of  the  two  systems. 

The  Boeing  Corporation  is  currently  under  contract  to 
the  Department  of  Defense  (DOD)  to  develop  the  full  ACEC, 
thus  providing  definitive  tests  across  a  wide  spectrum  of 
software  applications,  including  real-time  avionics  for 
collection  and  analysis  of  Ada  compiler  performance  data 
(Ada  Information  Clearinghouse  (AdalC),  1987). 

The  PIWG  benchmarks  (Squire,  1986)  are  similar  to  the 
ACEC  benchmarks.  Some  tests  are  included  in  both  test 
suites.  The  PIWG  test  suite  includes  more  tests  evaluating 
Ada  constructs  for  program  structure  and  control.  No  tests 
of  simple  Ada  constructs  (individual  math  functions,  assign¬ 
ments,  etc.)  are  included.  The  PIWG  test  suite  has  a  number 
of  tests  which  evaluate  the  same  language  feature  under  dif¬ 
ferent  conditions.  Most  tests  are  synthetic  tests.  Included 


within  the  benchmarks  are  (i)  routines  which  thwart  the 
compiler's  attempts  to  optimize  away  the  feature(s)  to  be 
measured,  and  (2)  a  dual  looping  structure  which  allows  the 
time  needed  to  record  timing  measurements  to  be  ignored.  The 
PIWG  benchmarks  were  also  designed  for  use  on  supermini  or 
larger  computers,  but  they  also  include  some  programs  which 
are  intended  to  allow  the  benchmarks  to  run  on  1750A  machines 
The  PIWG  benchmarks  also  include  an  elaborate  support  system 
for  obtaining  test  results. 

The  Air  Force  Wright  Aeronautical  Laboratories  (AFWAL) 
Avionics  Laboratory  is  currently  running  the  PIWG  benchmarks 
on  I750A  architectures  which  are  either  being  used  in  DOD 
funded  research  or  have  been  used  in  avionics  applications 
(Pitarys,  1987).  Additionally,  they  are  attempting  to  de¬ 
velop  benchmarks  specifically  oriented  to  avionics  applica¬ 
tions.  This  work  is  progressing  slowly  due  to  problems  with 
data  conversion  of  timing  information  and  with  the  lengthy 
amount  of  time  required  to  load  the  benchmarks  into  the  1750A 
machines  (Pitarys,  1987).  For  example,  it  currently  takes 
from  25-45  minutes  to  compile,  link,  load,  and  run  a  single 
benchmark  on  one  I750A  processor,  and  there  is  a  high  demand 
for  available  processors. 

During  his  thesis  research,  Witt  uncovered  a  number  of 
issues  which  were  pertinent  to  real-time  avionics  systems 
using  Ada  (Witt,  1985:28-41).  The  issues  he  raised  pertinent 
to  flight  control  software  are  tasking  considerations  and 


exception  handling.  He  executed  a  number  of  the  prototype 
ACEC  benchmarks  on  a  DEC  VAX-1  1/780  and  a  Data  General  com¬ 
puter  to  provide  insight  into  the  cost  of  using  Ada  to  imple¬ 
ment  real-time  avionics.  Witt  concluded  that,  since  many 
real-time  embedded  systems  issues  are  not  adequately  ad¬ 
dressed  in  the  prototype  ACEC,  developers  should  produce 
benchmarks  for  features  critical  to  their  applications  and 
contribute  them  to  the  public  domain  to  benefit  the  whole 
Ada  c  ommu n  i  t  y . 

Craine,  continuing  the  research  begun  by  Witt,  developed 
a  series  of  benchmarks  which  tested  the  overhead  associated 
with  task  rendezvous,  run-time  constraint  checking,  using 
many  tasks  or  many  refect  statements  within  tasks,  reordering 
of  Aclect  statements,  non-invoked  exceptions,  compiler  opti¬ 
mize  options,  pragma  suppress,  length  clauses,  and  unchecked 
deallocation  (Craine,  1986:44-65).  Craine  also  concluded 
that  further  examination  of  avionics  software  was  needed  to 
construct  more  representative  benchmarks  for  avionics. 

Much  of  the  previously  described  work  used  superminicom¬ 
puters,  or  larger  computers,  as  target  machines.  Flight 
control  software,  however,  is  executed  on  1750A-class  archi¬ 
tectures.  Thus,  many  existing  results  on  Ada  compiler  per¬ 
formance  are  not  necessarily  transferable  to  flight  control 
applications.  The  only  complete  benchmark  testing  which  has 
been  done  on  the  1 7  5 0 A  architectures  has  been  done  by  the 
contractors  producing  or  using  those  architectures  (Mellby, 


1987;  Startzman, 


1987).  But  such  testing  is  proprietary  and 


thus  is  unavailable  for  general  use 
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;  m  Design 


This  chapter  explains  the  design  of  a  system,  developed 
based  on  the  existing  partial  solutions  described  in  Chapter 
II,  for  addressing  the  thesis  problem  of  evaluating  Ada  com¬ 
pilers  for  flight  control  software  based  on  the  speed  of  ex¬ 
ecution  and  the  size  of  the  code  generated.  Evaluation  sys¬ 
tem  requirements,  alternative  evaluation  systems,  and  the 
the  design  of  a  system,  adapted  from  the  alternatives,  to 
meet  these  requirements  are  described. 


Compiler/RTS  Evaluat ion  Requirements 

Speed  of  execution  is  crucial  in  flight  control  appli¬ 
cations.  If  a  compiler/RTS  and  the  processor  it  is  hosted 
on  do  not  meet  a  system's  real-time  or  memory  space  con¬ 
straints,  the  compiler/RTS  and  processor  combination  is  un¬ 
suited  for  that  application  (Westermeier  and  Hansen,  1985: 
602;  Lahn  and  others,  u n d a t e d  :  I  -  2  )  .  So  a  system  used  to 
evaluate  compiler/RTS  and  processor  combinations  must  capture 
the  execution  time  of  the  produced  code  and  a  means  must  be 
available  to  determine  the  memory  space  required.  Next,  to 
confirm  elimination  of  transient  system  (both  hardware  and 
software)  effects,  the  results  of  the  system  tests  must  be 
repeatable.  Further,  the  system  must  be  able  to  isolate  the 
construct(s)  being  measured  from  other  language  constructs 
used  in  the  system  which  may  influence  the  results  of  the 
system  tests.  Finally,  the  validity  of  the  system  requires 


A.v:, 


that  the  tests  truly  represent  the  flight  control  domain 


in  both  the  number  and  types  of  language  constructs  used 


and  in  the  manner  in  which  the  constructs  are  used.  Also, 


any  constraints  on  values  must  be  incorporated.  For  example. 


if  the  value  of  a  variable  may  range  from  +25.0  to  -3.0  then 


the  system  must  insure  that  values  outside  that  range  are 


not  all  owed . 


Alternative  Evaluation  Systems 


The  three  basic  methods  for  evaluating  compiler  perfor¬ 


mance  are  application  domain  programs,  testing  a  complete 


application;  composite  benchmarks,  testing  integrated  fea¬ 


tures;  and  singular  benchmarks,  testing  an  individual  fea¬ 


ture  (Clapp  and  others,  1986:760;  C r a  i  n e ,  I  9 8 6  :  I  3  )  . 


To  embed  timing  routines  within  actual  flight  control 


application  programs  would  insure  that  the  timing  evaluation 


reflected  the  true  nature  of  flight  control  software. 


This  is  an  established  reliable  method  for  quanti¬ 
tatively  assessing  overall  time  and  space  perfor¬ 
mance  characteristics  of  the  generated  object  code 
when  the  intended  application  domain  is  well  under¬ 
stood. 

(Bassman  and  others,  1985:151) 


However,  recall  from  Chapter  II  that  flight  control  software 


is  currently  written  mostly  in  various  assembly  languages 


and/or  JOVIAL.  Running  application  programs  in  these  lan¬ 


guages  would  not  illuminate  Ada’s  suitability  for  flight 


control  software.  For  this  reason,  current  application 


domain  programs  were  not  used 
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Composite  benchmark  S  (or  Synthetic  benchmarks)  may  also 
be  used  to  evaluate  the  speed  of  execution  of  code  generated 
by  a  compiler.  In  composite  benchmarks,  a  number  of  language 
features  are  incorporated  into  one  test  program.  The  lan¬ 
guage  features  in  composite  benchmarks  are  executed  with  the 
same  frequency  as  they  appear  in  the  actual  application  do¬ 
main.  The  use  of  composite  benchmarks  thus  requires  a  sam¬ 
ple  of  the  application  domain  software  or  detailed  design 
documents  to  be  examined  to  determine  the  frequency  of  use 
of  language  features.  The  AFTI/F-16  design  documents  con¬ 
tain  very  detailed  pseudocode  and  execution  sequence  charts 
which  contain  all  the  information  needed  to  construct  com¬ 
posite  benchmarks.  Because  flight  control  software  includes 
a  rich  mixture  of  language  constructs  (Landy  and  others, 
1986:9-1  to  9-15;  Ramage  and  others,  1981:21-26),  composite 
benchmarks,  modeling  interaction  of  constructs,  more  accu¬ 
rately  reflect  flight  control  software  than  singular  bench¬ 
marks.  The  composite  benchmarks  developed  for  this  research 
are  very  similar  to  application  domain  benchmarks  because 
they  were  derived  from  application  domain  designs  and  code. 

The  final  approach  considered  was  the  use  of  singular 
benchmarks >  which  evaluate  specific  language  features.  This 
method  requires  isolating  each  feature  to  be  tested,  achiev¬ 
ing  accurate  and  repeatable  results,  and  eliminating  the  ef¬ 
fect  of  the  computer  system  (other  than  the  c omp  i  1 e r /RTS )  on 
the  test  (Clapp  and  others,  1986:760-761).  For  singular 


benchmarks  to  be  useful,  isolations  of  features  in  an  applica 
tion,  and  a  time  breakdown  of  feature  use  within  the  applica¬ 
tion  are  needed.  As  an  example  of  why  such  isolation  of  a 
single  feature  is  not  feasible  for  flight  control  software, 
consider  the  following.  The  calculation  of  a  value  for  an 
output  to  a  control  surface  is  based  on  the  control  surface's 
last  position  and  the  current  aircraft  speed,  altitude,  and 
direction.  With  different  values  for  the  speed,  altitude, 
and  direction  inputs,  the  calculation  involves  varying  number 
of  mathematical  operations.  Thus  the  time  required  to  ob¬ 
tain  the  output  value  depends  on  not  only  the  number  of 
mathematical  operations  but  also  the  time  needed  to  deter¬ 
mine  the  preconditions  of  the  calculation.  Flight  control 
software  is  filled  with  such  interdependencies  (Landy  and 
others,  1986:9-1  to  9-15;  Ramage  and  others,  1981:21-26). 
Consequently,  singular  benchmarks  were  not  used. 


System  Ove  rview 

The  system  designed  to  solve  the  thesis  problem  state¬ 
ment  required  tests  be  designed  which  evaluate  Ada's  ability 
to  implement  flight  control  software. 

Flight  control  software  must  first,  therefore,  be  char¬ 
acterized  before  a  system  can  be  designed  which  will  examine 
the  effects  of  using  Ada  for  flight  control  software.  The 
problem  with  characterizing  flight  control  software  in  a 


generic  fashion  is  that  each  aircraft's  flight  control 


surfaces  may  differ  in  both  number,  size,  and  location. 


Thus,  the  control  law  computations  will  be  less  or  more 
complicated  which  leads  to  higher  or  lower  time  and  space 
requirements.  Also,  computer  resources  and  the  way  in  which 
these  resources  are  used  vary  between  aircraft.  Some  sys¬ 
tems  dedicate  separate  computers  to  compute  control  laws  for 
different  axes  ( Landy  and  others,  1986:3-1)  while  other  sys¬ 
tems  use  all  computers  for  all  axes  (Ramage  and  others, 
1981:4-7).  For  example,  the  algorithm  to  compare  two  values 
for  consistency  is  much  simpler  than  the  algorithms  to  com¬ 
pare  three  values,  taken  two  at  a  time. 

The  AFTI/F-I6  is  representative  of  current  fighter 
aircraft  because:  (I)  it  is  slightly  unstable  which  provides 
the  ability  to  increase  performance,  (  2  )  it  is  a  fly-by-wire 
system  with  integrated  avionics  applications,  and  (3)  its 
redundancy  management  scheme  isolates  and  adapts  to  system 
failures  (Barfield,  1987;  Toolean,  1987;  Johnston,  1987; 
DeThomas,  1987).  The  overall  design  of  the  AFTI/F-16  is 
representative  of  the  current  trend  of  redundant,  fly -by- 
wire,  slightly  unstable  aircraft  (Joslin,  1987;  Toolean, 
1987).  For  the  preceding  reasons  all  software  developed  to 
determine  Ada's  ability  to  implement  flight  control  software 
used  the  system  design  and  algorithms  for  the  AFTI/F-16 
aircraft . 

Next,  with  flight  control  software  having  been  charac¬ 
terized,  the  functions  within  flight  control  software  which 
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are  the  critical  cost  drivers  must  be  determined  so  pertinent 
tests  can  be  developed.  There  are  two  critical  factors  in 
flight  control  software,  execution  time  and  code  size.  As 
shown  in  Chapter  II,  the  AFTI/F-16  has  five  main  functions 
which  are  used  in  flight:  the  executive,  control  law  compu¬ 
tation,  selection/monitoring  of  inputs/outputs,  failure 
management,  and  pilot  interface.  These  functions  were  ex¬ 
amined  to  determine  the  language  constructs  which  they  use. 
Manually  converting  the  diagrams  and  algorithms  in  the 
design  documents  for  the  AFTI/F-16  to  Ada  provided  the  do¬ 
main  definition  of  flight  control  software.  The  conversion 
from  flight  control  system  design  to  Ada  involved  implement¬ 
ing  limits  on  values  and  conditional  inputs  with  conditional 
statements,  i n c o r po r a t i n g  all  mathematical  computations,  and 
initializing  all  constants  to  the  values  used  in  the  design. 
All  benchmark  tests  designed  were  based  on  this  definition. 

B  e  n  c  h  m  a£_k  T  e  s  t  s 

The  following  sections  explain  which  flight  control 
functions  were  analyzed  and  the  method  by  which  tests  sim¬ 
ulating  these  routines  were  constructed. 

Control  Laws.  As  defined  in  Chapter  II,  flight  control 
law  computations  are  mathematical  solutions  to  flight  dynam¬ 
ics  equations.  These  computations  are  needed  to  keep  the 
aircraft  stable  during  flight.  Also  recall  from  Chapter  II 
that  in  one  typical  application  30  percent  of  the  time  and 


34  percent  of  memory  is  devoted  to  control  law  computations; 
thus,  the  control  law  function  is  a  critical  cost  driver  in 
flight  control  software.  Conditional  statements  which 
determine  the  state  of  the  aircraft  and  arithmetic  operations 
and  assignment  statements  based  on  these  conditions  are  the 
Ada  constructs  used  in  this  functional  module.  Because  the 
conditions  evaluated  by  the  conditional  statements  control 
which  arithmetic  operations  will  be  executed,  both  the  con¬ 
ditional  statements  and  arithmetic  statements  are  the  Ada 
constructs  which  drive  the  cost  of  control  law  computation. 

The  AFTI/F-16  has  four  modes  -  standard  normal,  air-to- 
air  gunnery,  a i r - t o - s u r f a c e  gunnery,  and  bombing  (Yousey  and 
others,  1984:3-68  to  3-69).  Each  mode  tailors  aircraft  per¬ 
formance  to  enhance  handling  or  stability  for  a  particular 
mission,  as  described  by  the  mode  names.  The  standard  normal 
mode,  from  which  all  the  other  modes  were  derived,  was  chosen 
for  development  of  the  benchmark  because  it  is  representative 
of  all  control  law  computations  (Barfield,  1987;  Johnston, 
1987;  DeThomas,  1987).  The  benchmark  reflected  the  frequency 
of  the  Ada  constructs  identified  as  the  cost  drivers  for 
control  laws.  Because  the  benchmark  is  an  Ada  implementation 
of  actual  flight  control  software  it  will  provide  a  good 
indication  of  whether  one  compiler/RTS  and  processor  is  more 
suitable  than  another  combination  for  flight  control  law 
computations  in  terms  of  the  speed  of  execution  and  the 
memory  needed  to  implement  the  benchmark. 


Gain  Table  Interpolat  ion.  A  separate  element  in  flight 
control  law  computation  is  the  computation  of  gains,  limits, 
and  coefficients  (Henley  and  others,  1984:13-26  to  13-30). 

The  values  of  these  parameters  are  determined  based  on  var¬ 
ious  flight  data  such  as  angle-of-attack,  air  pressure,  and 
altitude.  The  values  are  determined  by  interpolating  be¬ 
tween  data  points  which  are  in  tables  (arrays)  in  the  flight 
control  computer.  The  criticality  of  these  computations  is 
based  on  the  same  reasoning  used  for  the  control  law  compu¬ 
tations.  The  time  and  space  criticality  of  the  gain  values 
is  presumed  because  they  are  needed  for  the  control  law 
computations  (Henley  and  others,  1984:13-26). 

A  compensation  filter  frequency  gain  was  selected  for 
benchmark  testing  because  it  represented  a  typical  gain 
table  i n t e r po 1  a t  i  o n  (Barfield,  198  7  ;  Joslin,  1987  ).  The 
benchmark  embodies  a  method  in  which  all  gain  values  could 
be  computed.  The  benchmark  is  an  Ada  implementation  of  a 
method  to  compute  double  interpolations  of  actual  flight 
control  data  and  thus  will  provide  a  good  indication  whether 
a  compiler/RTS  and  processor  is  more  suitable  than  another 
combination  for  flight  control  law  computations  in  terms  of 
the  speed  of  execution  and  the  memory  needed  to  implement 
the  benchmark. 

Redundancy  Management .  Redundancy  management  is  a  col¬ 
lective  term  which  encompasses  selector/monitor  and  failure 
management  functions.  These  functions  are  required  to  select 


and  monitor  sensor  inputs  and  the  outputs  to  control  surface 
actuators.  Failure  management  is  invoked  upon  determining 
that  a  failure  has  occurred.  Redundancy  management  is 
necessary  to  insure  that  the  aircraft  does  not  erroneously 
act  upon  incorrect  commands  given  by  failed  hardware  or  soft¬ 
ware.  In  addition  to  their  importance  in  safety,  these  func¬ 
tions  are  critical  because,  in  one  typical  application,  they 
use  43.6  percent  of  the  time  and  23.3  percent  of  the  space 
used  by  flight  control  software  (Table  II,  page  14).  The 
Ada  constructs  used  in  redundancy  management  are  conditional 
statements,  mathematical  operations,  and  procedural  calls. 

The  developed  benchmark  is  an  Ada  implementation  of  the 
algorithm  used  to  monitor  the  leading  edge  flap  ( L  E  F  )  .  The 

M 

®  LEF  monitor  function  was  chosen  because  it  involves  all 

aspects  of  redundancy  management:  monitoring  input  values, 
checking  for  inconsistencies  between  different  input  values 
and  the  same  input  values  from  different  computers,  checking 
inputs  and  outputs  for  consistency,  and  calling  failure 
management  when  conditions  warrant  it. 

Test  Select  ion 

The  functional  areas  for  which  tests  were  developed  are 
the  areas  which  required  the  most  time  and  memory  space  in 
one  typical  flight  control  software  implementation.  The 
other  areas  were  not  chosen  for  benchmark  development  because 
they  either  are  not  used  during  flight  or  are  in  use  a  much 


smaller  percentage  of  in-flight  time  and  use  much  less  space 
as  compared  to  the  chosen  functional  areas.  The  benchmarked 
functional  areas  use  80.3  percent  of  the  in-flight  time  and 
67.9  percent  of  the  memory  space  used  for  flight  control 
sot tware . 
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I  V .  Detailed  Design 

This  chapter  explains  the  steps  taken  in  developing  and 
executing  the  software  necessary  to  measure  the  time  needed 
to  execute  Ada  constructs  identified  in  Chapter  II  as  the 
critical  cost  drivers  in  flight  control  a p p  1  i  c a t  i  o n s  .  Each 
test  description  presents  the  function  of  the  test  and  ex¬ 
plains  the  process  used  to  evaluate  the  tested  function.  In 
Chapter  III  the  selection  and  importance  of  the  tested  func¬ 
tions  as  the  critical  cost  drivers  for  flight  control  soft¬ 
ware  was  explained.  The  following  sections  explain  in  more 
detail  how  the  testing  was  conducted  and  why.  The  sub-head¬ 
ings  are  the  same  as  the  sub-headings  in  Chapter  III. 

Control  Laws 

Function.  The  function  of  this  test  is  to  measure  the 
speed  of  execution  of  the  control  law  computations  found  in 
flight  control  software.  Control  law  operations  are  critical 
for  two  reasons,  as  explained  in  Chapter  II;  they  consume  30 
percent  of  the  time  that  flight  control  software  is  execut¬ 
ing,  and  they  are  necessary  to  keep  the  aircraft  in  stable 
flight. 

Descript  ion  .  Initially,  the  documents  from  the  IFFC 
(UCCS,  1986),  ABICS-II  (Landy  and  others,  1986),  and  the 
AFTI/F-16  (Henley  and  others,  1984)  projects  were  examined 
and  the  frequency  distribution  of  language  constructs  de¬ 
termined  by  manually  counting  the  constructs  and  noting  the 
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types  of  operands  and  operations,  where  appropriate.  The  two 
F- ! 5  software  products  used  floating  point  calculations  while 
the  AFTI/F-16  software  used  fixed  point  calculations.  Also, 
the  different  number  of  flight  control  computers,  the  manner 
in  which  they  are  used,  and  the  different  control  law  com¬ 
putations  used  for  each  aircraft  made  it  impractical  to 
make  one  benchmark  representative  of  both  aircraft.  A 
single  benchmark  could  not  be  developed  because  the  number 
of  language  constructs  required  to  implement  the  control  law 
computations  varied  from  one  aircraft  to  the  other  by  over 
50  percent  of  the  total  for  the  two  aircraft. 

The  next  step  was  to  decide  whether  to  make  dual  bench¬ 
marks,  one  for  each  aircraft,  or  to  concentrate  on  one  air¬ 
craft.  Recall  from  Chapter  III  that  the  AFTI/F-16  was  chosen 
because  it  more  closely  represented  present  and  near  future 
fighter  aircraft.  Table  III  contains  the  percentage  of 
language  constructs  and  operands  used  in  the  AFTI/F-16  con¬ 
trol  law  computations.  The  benchmark  developed  to  evaluate 
control  law  computation  is  an  Ada  implementation  of  AFTI/F-16 
control  laws  and  contains  the  same  percentage  of  constructs 
and  operands  as  shown  in  Table  III  (in  fact,  the  benchmark 
contains  the  same  number  of  constructs  and  operands).  The 
software  design  documentation  for  the  AFTI/F-16,  specifically 
the  algorithms  and  values  in  Chapter  13  and  Appendices  B,  C, 
and  E,  provided  the  definition  of  a  typical  flight  control 
software  design  (Henley  and  others,  1984).  The  benchmark 


Table  III.  Language  Constructs  and  Operands  Used  in 
AFTI/F-16  Flight  Control  Law  Computations 


Multiplications  -  32  % 
Divisions  -  6% 
Add  itions  -17% 
Subtractions  -  6  % 
Assignments  -  20  % 
Absolute  Values  -  2  % 
Conditionals  -  17  % 
Variables  -70% 
Constants  -30% 


implements  the  standard  normal  mode  control  laws  for  the 
AFTI/F-16.  During  development,  it  became  clear  that  not 
only  the  compilers  and  processors  but  also  the  manner  in 
which  the  code  was  written  could  have  a  noticeable  effect 
on  the  execution  speed  of  an  application.  Because  speed  of 
execution  is  so  critical  to  flight  control  software,  this 
benchmark  was  coded  in  two  styles:  a  modular,  information¬ 
hiding  style  where  variables  and  constants  were  declared  and 
used  in  localized  modules,  and  a  global  style  where  all  var¬ 
iables  and  constants  were  declared  in  the  main  procedure  and 
thus,  usable  in  all  modules.  Appendix  A  has  examples  of 
the  two  coding  styles  used.  The  benchmark  uses  a  set  of 
data  designed  to  follow  a  normal  path  through  the  control 


laws. 


A  normal  path  is  defined  as  the  path  where  none  of 


the  structural  or  performance  limits  of  the  aircraft  is 
approached.  A  normal  path  was  chosen  because  it  represents 
the  normal  operating  range  of  the  aircraft  (Hicks,  1987; 
Barfield,  1987).  Thus  the  benchmark,  as  designed,  is  only 
completely  suitable  for  evaluating  Ada  c om p  i  1 e r s  /  !  7  5 0  A 
processsors  for  the  AFTI/F-16  in  standard  normal  mode  during 
a  normal  flight  path;  however,  these  limitations  are  miti¬ 
gated  by  the  opinions  expressed  in  Chapter  III  and  pre¬ 
viously  in  this  chapter  that  the  AFTI/F-16  is  representative 
of  current  fighter  aircraft  and  the  non-standard  normal 
modes  of  operation  are  only  slight  variations  on  the  stan¬ 
dard  normal  mode. 

Gain  Table  Interpolat  ion 

Funct  ion.  The  function  of  this  test  is  to  measure  the 
speed  of  execution  of  accessing  data  in  a  gain  table  and 
interpolation  of  a  value  between  data  points.  Gain  table 
access  and  interpolation  are  critical  because  if  gain  table 
calculations  are  too  slow  the  control  laws  will  not  have 
valid  data  for  computation  and  aircraft  performance  and 
stability  could  be  adversely  affected. 

Descript  ion  .  The  values  to  be  used  in  this  benchmark 
were  extracted  from  Appendix  E  and  Chapter  13  of  the  soft¬ 
ware  mechanization  for  the  AFTI/F-16  (Henley  and  others, 
1984).  Appendix  B  of  this  thesis  contains  a  sample  of  the 


double  interpolation  method  used  between  four  data  points 
in  the  benchmark  designed  to  represent  this  function  (Bar¬ 


field,  1987).  The  benchmark  contains  a  representative  gain 
table  and  interpolation.  One  sample  was  considered  suffi¬ 
cient  because  the  other  gain  tables  and  their  interpolations 
use  the  same  methods  (Barfield,  1987).  An  estimate  of  the 
time  needed  to  compute  additional  gain  values  can  be  obtained 
by  multiplying  the  benchmark  result  by  the  desired  number. 


Kedu n  d  a  n  c  y  Management 

Recall  from  Chapters  II  and  III  that  redundancy  manage¬ 
ment  is  used  to  monitor  inputs/outputs,  make  comparisons  of 
the  data  received,  and  act  on  the  results  of  those  compar¬ 
isons.  One  benchmark  was  developed  for  this  function.  The 
leading-edge  flap  (LEF)  monitor  was  chosen  because  it  includes 
all  the  operations  of  redundancy  management  as  stated  above. 

A  single  benchmark  is  suitable  because  it  is  representative 
of  the  complete  redundancy  management  area. 

The  LEF  monitor  is  a  series  of  conditional  statements 
with  a  few  mathematical  calculations  and  a  call  to  the  failure 
management  procedure  when  needed  (Henley  and  others,  1984: 
Chapter  6).  The  algorithms  for  the  LEF  monitor  were  coded 
in  Ada.  The  code  was  initially  designed  not  to  call  the 
failure  management  routine  because  it  is  not  a  critical  cost 
driver,  as  described  in  Chapters  II  and  III,  however;  this 


meant  that  the  effect  of  detecting  and  operating  with 


failures  was  not  evaluated  for  the  LEF  monitor  algorithm. 

To  test  operation  under  these  conditions,  a  second  version  of 
the  benchmark  was  developed  which  included  detecting  failures 
and  operating  the  algorithm  under  failure  conditions.  The 
second  version  provided  a  means  to  gauge  how  the  benchmark 
operates  under  differing  sets  of  conditions.  Because  the 
benchmark  was  developed  from  the  same  algorithms  as  used  in 
the  actual  LEF  monitor  for  the  AFTI/F-16,  the  results  provide 
a  good  comparative  evaluation  of  varying  p r o c e s s o r / c om p  i  1 e r 
combinations'  abilities  to  implement  redundancy  management 
software. 

Test  Procedures 

A  support  system  adapted  from  the  PIWG  benchmark  sup¬ 
port  package  was  used  to  obtain  timing  data  and  output  the 
timing  data  to  a  monitor  for  recording.  To  determine  if 
support  software  would  affect  the  results,  two  different 
test  programs  were  run  with  the  support  software  and  without 
it.  Because  there  was  no  difference  for  either  program  in 
the  times  recorded,  it  was  assumed  the  support  software  did 
not  affect  timing  measurements. 

To  eliminate  any  effects  obtaining  timing  measurements 
might  have  on  timing  data  the  dual  loop  benchmark  method  was 
used.  In  this  method,  a  contact  Iccp  is  used  to  eliminate 
the  effects  of  calling  a  timer  function.  The  control  loop 
contains  only  enough  code  (generally  a  call  to  a  remote 


procedure)  to  keep  it  from  being  eliminated  by  the  compiler. 
The  loop  contains  the  same  code  as  the  control  loop 


and  the  feature(s)  to  be  measured.  The  difference  in  the 
time  required  for  the  control  loop  and  the  time  required  for 
the  test  loop  is  the  time  required  to  execute  the  feature(s) 
being  measured.  Figure  !  contains  an  outline  for  this  type 
of  benchmark.  To  insure  the  timing  measurement  is  greater 
than  the  smallest  time  the  system  clock  can  record  the  loop 
is  executed  until  the  measured  time  is  greater  than  the  clock 
resolution.  The  time  to  execute  the  benchmark  is  determined 
by  dividing  the  number  of  iterations  into  the  elapsed  time. 


Control_start  : =  Timer; 

Loop  for  1  to  Count 
Remo  t  e ( )  ; 

End  Loop; 

Control_stop  :=  Timer; 

Test_start  :=  Timer; 

Loop  for  1  to  Count 
Remo  t  e ( )  ; 

Feature_to_b  e_me a  s  u  r  e  d ; 

End  Loop; 

Test_stop  :=  Timer; 

Feature_Time  :=  ( Test_s  top  -  Test_start) 

-  (Control  stop  -  Control  start) 


If  Feature_Time  >  minimum  system  time  then 
Exit; 

Else 

Count  :=  Count  +  1; 

End  loop; 


Figure  1.  Dual  Loop  Benchmark 


On  multi-user  systems,  timing  data  is  often  invalidated 
by  the  operating  system  sharing  time  among  users  and  periph¬ 
eral  devices  such  as  printers  and  disk  drives  depending  upon 
the  demands  placed  on  the  system.  Thus,  widely  varying  times 
are  possible  for  the  same  benchmark.  Because  I750A  proces¬ 
sors  are  single-user  devices  with  no  peripheral  devices  it 
was  assumed  variance  would  not  be  a  problem.  To  test  this 
assumption  the  test  programs  discussed  earlier  in  this  chap¬ 
ter  were  run  five  times  on  the  I750A  architecture:  the  times 
were  identical  for  each  run.  On  multi-user  systems,  var¬ 
iances  always  appeared  among  five  or  fewer  runs. 

To  obtain  timing  data,  the  PIWG  benchmarks  for  1750A 
processors  use  the  Ada  CALENDAR  package,  which  measures 
wall-clock  time  and  not  CPU  time.  To  determine  if  the  PIWG 
method  was  accurate  an  assembly  language  routine  was  de¬ 
veloped,  in  collaboration  with  Joyce  and  Pitarys,  which  used 
a  real-time  clock,  bypassing  the  Ada  package  (Joyce,  1987; 
Pitarys,  1987).  The  same  sample  tests  were  run  using  both 
methods  to  record  times.  Assembly  language  routines  were 
used  in  the  research  because  the  resolution  of  the  real-time 
clock  was  finer  than  the  resolution  in  the  Ada  calendar 
package  and  produced  more  accurate  timing  data. 


V .  Test  Analysis 

This  chapter  evaluates  the  validity  of  the  benchmark, 
tests  for  solving  the  thesis  problem:  to  show  the  compar¬ 
ative  capability  of  an  Ada  compiler/RTS  and  1750A  processor 
combination  to  effectively  and  efficiently  implement  flight 
control  software.  This  capability  is  judged  upon  the  abil¬ 
ity  of  a  combination  to  implement  the  flight  control-critical 
Ada  constructs  and  flight  control  algorithms  described  in 
Chapters  III  and  IV.  Detailed  results  of  the  developed 


b  e  n  c  h  m  a 

rk 

tests 

run  on  two 

1  7  5  0  A 

processors 

using  two  Ada 

comp:  !  e 

r  s 

is  at 

Appendix  C. 

The 

eompi lers 

and  processors 

tested 

i  n 

this 

research  are 

labeled  generic 

ally  throughout 

»  the  results  to  permit  the  widest  distribution  of  the  thesis. 

Machine-readable  versions  of  the  benchmarks  may  be  obtained 
from  the  Air  Force  Institute  of  Technology'. 


Va  1  i  d  a  t  i o n  Met h  o d 

Validation  that  a  benchmark,  provides  a  means  to  judge 
comparative  capability  of  I750A  processor  and  Ada  compiler 
combinations  is  based  on  the  opinions  of  personnel  know¬ 
ledgeable  in  aircraft  flight  controls  and  flight  control 
software.  Validation  is  handled  separately  for  each  bench¬ 
mark. 


Department  of  Mathematics  and  Computer  Science,  WPAFB 
OH  4  54  33,  (513)  255  -  3098  . 


Control  Laws 


The  control  law  computation  benchmark  is  suitable  for 
evaluating  Ada's  ability  to  implement  control  law  computa¬ 
tions.  The  benchmark  provides  an  indication  about  the  time 
and  space  needed  to  implement  a  typical  aircraft's  flight 
control  software  in  Ada.  The  performance  during  atypical 
conditions  and  the  way  the  flight  control  software  handles 
these  conditions  should  be  considered  in  order  to  obtain  a 
better  comparison  (DeThomas,  1987). 

The  control  law  computation  benchmark  is  valid,  to  a 
degree,  across  aircraft  because,  in  general,  the  same  types 
of  aerodynamic  computations  are  needed  to  keep  any  aircraft 
stable.  The  degree  of  validity  will  depend  on  the  similarity 
between  the  aircraft  for  which  an  evaluation  of  compilers  is 
to  be  conducted  and  the  AFTI/F-16.  The  benchmark  would  be  a 
better  evaluation  if  it  included  a  framework  to  alter  data 
dynamically.  For  example,  the  benchmark  would  be  improved 
if  it  included  a  complete  scenario  from  take-off  to  landing 
the  aircraft  (Barfield,  1987). 

The  control  law  benchmark  does  give  an  indication  of 
the  comparative  capabilities  of  Ada  compiler/RTS  and  1750A 
processor  combinations  to  operate  in  the  standard  normal 
mode  of  operation.  A  better  indication  could  be  achieved  by 
encoding  more  of  the  modes  of  operation  or  computing  more  of 
the  variable  data  rather  than  assigning  set  values  to  the 
variables  (Hicks,  1987). 


The  control  law  benchmark  gives  an  indication  of  how 
well  an  Ada  compiler/RTS  and  processor  computes  control 
laws.  Increasing  the  number  of  paths  taken  through  the 
control  laws  to  test  the  effect  of  different  conditions 
would  be  a  suitable  extension  of  the  benchmark.  For  ex¬ 
ample,  widening  the  range  of  the  data  inputs  (which  drives 
the  path  the  computations  take)  would  provide  a  more  robust 
evaluation  of  the  compiler's  ability  to  keep  the  aircraft 
stable  (Lewantowicz,  1987). 

Gain  Table  I_nt_e  rpolat  ion 

The  gain  table  interpolation  benchmark  provides  useful 
data  to  compare  compilers  for  flight  control  software  because 
( I )  they  calculate  gains  accurately;  and  (2)  the  calculation 
of  gains  is  a  critical  portion  of  flight  control  software. 
Encoding  multiple  gain  tables  would  provide  a  better  indica¬ 
tion  of  Ada's  suitability,  especially  in  generated  code 
size  (Barfield,  1987). 

The  gains  table  interpolation  benchmark  is  useful  in 
determining  code  execution  speed  and  size,  because  gains  for 
are  calculated  in  basically  the  same  way  for  different  types 
of  aircraft.  The  gain  table  interpolation  could  be  enhanced 
by  including  different  types  of  interpolation.  For  example, 
inclusion  of  a  gain  table  which  has  fewer  data  points  or 
a  gain  table  which  is  entered  with  only  one  input  (Joslin, 

198  7  ). 


2 


Redundancy  Management 


The  redundancy  management  scheme  of  the  AFTI/F-16  pro¬ 
vides  an  indication  of  Ada's  suitability  for  use  across  air¬ 
craft  because  the  AFTI/F-16  design  is  being  used  to  design 
redundancy  management  schemes  for  other  aircraft.  The  LEF 
monitor  portion  of  the  AFTI/F-16  design  does  implement  all 
of  the  major  elements  of  the  redundancy  management  scheme 
and  is  representative  of  the  overall  scheme  (Hicks,  1987). 

Although  it  may  not  encompass  the  complete  range  of 
redundancy  management  software,  the  benchmark  provides  a 
partial  method  for  evaluating  Ada's  ability  to  implement 
another  element  of  flight  control  software  (Barfield,  1987). 

The  LEF  monitor  benchmark  provides  one  point  at  which 
to  judge  a  compiler's  ability  to  implement  flight  control 
software.  The  test  should  be  expanded  to  include  more  types 
of  conditions  (i.e.,  additional  mixtures  of  failures)  to  see 
what,  if  any  interdependencies  exist  and  determine  their 
effect  on  execution  speed  (DeThomas,  1987). 

The  LEF  monitor  provides  a  good  indication  of  a  1750A 
processor  and  compiler  combination's  ability  to  execute 
redundancy  management  schemes  because  it  incorporates  con¬ 
ditional  execution,  procedural  calls,  and  a  mathematical 
model  which  are  the  major  functions  of  any  redundancy  man¬ 
agement  scheme.  Including  more  of  the  redundancy  management 
scheme  in  the  benchmark  would  enhance  the  value  of  both  the 
execution  speed  and  code  size  measurements  (Joslin,  1987). 


The  developed  benchmarks,  based  on  Che  expert  eval¬ 
uations  in  the  previous  sections,  predict  the  utility  of 
compiler/RTS  and  compiler  combinations  for  flight  control 
software  with  the  following  limitations: 

1.  Any  aircraft  which  substantially  differs 
from  the  AFTI/F-16  in  implementation  of  flight 
control  software  will  receive  results  which 
may  not  be  transferable  to  that  aircraft. 

The  judgement  of  whether  an  aircraft  is 
substantially  different  is  subjective  in 
nature  and  thus  is  left  to  the  individual 
user  to  determine. 

2.  The  benchmarks  were  designed  using  the 
standard  normal  mode  of  operation  and  well 
within  the  performance  limits  of  the 
aircraft.  Judgements  on  utility  at  the 
limits  of  the  aircraft  can  easily  be 
implemented  by  changing  the  variables  in 
the  benchmark.  For  other  than  standard 
normal  mode,  additional  modules  would  need 
to  be  coded. 


V  I  .  Conclusions  and  Recommendat  ions 

This  chapter  provides  an  explanation  of  how  well  the 
thesis  objectives  were  achieved,  conclusions  reached  based 
on  the  results  of  the  thesis  research,  additional  observa¬ 
tions  which  were  uncovered  during  the  research,  and  recom¬ 
mendations  for  further  research.  The  primary  objective  of 
this  research  was  to  develop  tests  which  enabled  different 
Ada  compiler/RTS  and  1750A  processor  combinations  to  be 
compared  in  execution  speed  and  code  generation  size  for 
flight  control  software  suitability.  Two  additional  ob¬ 
jectives  were  needed  to  meet  the  primary  objective:  (I) 
to  characterize  flight  control  software  so  suitable  tests 
could  be  developed,  and  (2)  to  run  the  developed  tests  on 
compiler/processor  combinations  representative  of  current 
processors  being  used  in  DOD  aircraft  or  research  to  insure 
the  tests  would  run  in  the  target  environment. 

A  thieve  m  e  n  t  o_f  Object  ives 

The  characterization  of  flight  control  software  involved 
examining  current  software  for  general  similarities.  The 
examination  showed  that  a  general  solution  was  not  entirely 
realizable  so  the  current  trend  in  fighter  aircraft  was 
determined  and  the  characterization  made  to  fit  this  trend. 
The  AFTI/F-16  aircraft  was  chosen  as  the  general  character¬ 
ization  of  high-performance  fighter  aircraft. 
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The  development  of  benchmarks  involved  determining  tne 
Ada  constructs  which  are  the  critical  cost  drivers  in  the 
previous  characterization  and  developing  programs  (the 
benchmarks)  which  were  representative  of  the  use  of  these 
constructs  in  the  application  domain.  This  was  done  by 
examining  the  functions  of  flight  control  software  which 
use  the  most  time  and  space,  selecting  them  as  the  critical 
routines,  examining  these  routines  to  determine  the  Ada 
constructs  used  in  them,  and  writing  benchmarks  to  test 
the  cost  of  implementing  the  rout  ines/Ada  constructs.  Three 
benchmarks  were  developed  along  with  support  software  used 
to  measure  execution  time  and  isolate  the  features  to  be 
tested.  This  objective  was  partially  successful  in  that 
portions  of  the  flight  control  functions  which  are  the 
critical  cost  drivers  were  encoded  in  Ada  and  the  suitabil¬ 
ity  of  the  developed  benchmarks  was  endorsed  by  experts  in 
flight  controls  and  flight  control  software,  as  described 
in  Chapter  V. 

The  developed  benchmarks  were  executed  on  two  1750A 
processors  using  two  compilers.  The  compilers  and  processors 
used  were  chosen  based  on  their  use  in  DOD-sponsored  research 
and  development.  The  benchmarks  were  successfully  compiled 
and  linked  on  both  compilers  for  both  processors.  When 
the  compiled  code  was  executed  only  one  processor  ran  both 
compiled  versions  of  the  benchmarks;  the  other  processor 
ran  no  programs  from  one  compiler  and  only  the  smaller 
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benchmarks  from  the  other  compiler. 


This  objective  was  par¬ 


tially  achieved  because  the  one  processor  did  not  run  all 
benchmarks.  Based  on  the  findings  of  this  research  and 
concurrent  research  efforts  it  was  concluded  that  the  pro¬ 
cessor  was  at  fault  (Pitarys,  1987). 


Conclusions 

The  developed  benchmarks  are  valid  for  aircraft  which 
have  flight  control  software  implemented  similar  to  the 
AFTI/F-16;  any  aircraft  which  differs  significantly  in  any 
one  of  the  flight  control  functional  areas  from  the  AFTI/F-16 
will  obtain  results  less  representative  of  its  application 
domain.  As  described  in  Chapter  V  the  difference  between 
aircraft,  and  thus  the  degree  of  suitability  of  the  bench¬ 
marks,  is  left  to  the  i  nd  i  v  i  du a  1 ( s  )  wishing  to  use  the 
benchmarks.  In  general,  the  opinions  of  experts  cited  in 
Chapter  V  describe  the  benchmarks  as  representative  of 
current  fighter  aircraft. 

Accurate  and  repeatable  measurements  are  achievable  if 
care  is  taken  to  eliminate  system  effects  and  the  !750A's 
real-time  clocks  are  interfaced  to  the  timing  measurement 
software . 


Addit  ional  Observat  ions 

A  compiler  used  for  flight  control  software  should 
include  ADDRESS  CLAUSES  because  they  allow  access  to  the 
underlying  hardware.  ADDRESS  CLAUSES  allow  designers  to 
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have  direct  access  to  inputs  and  outputs  which  are  allocated 
to  specific  memory  locations  which  mitigates  the  need  for 
routines  to  get  and  send  data.  Additionally,  a  programmer 
will  know  that  the  data  is  always  at  the  specified  location 
with  no  need  to  initialize  the  data  in  software  or  insure 
the  run-time  system  has  not  overwritten  or  optimized  out 
the  data. 

Particular  attention  should  be  paid  to  compiler  limita¬ 
tions.  Any  limits  may  affect  the  manner  in  which  code  is 
developed.  For  example,  if  only  100  external  names  can  be 
referenced  in  a  procedure,  then  many  more  local  variables 
will  be  used,  which  can  affect  execution  speed  (as  described 
in  Appendix  C).  Similarly,  the  total  number  of  variables 
allowed,  limits  on  the  number  of  units  allowed  to  be  WITHed, 
and  nesting  limits  should  be  examined  to  insure  a  particular 
application  does  not  exceed  the  limits  of  the  compiler. 

Recommendat  ions  for  Further  Research 

Four  areas  are  indicated  for  further  research: 

(I)  expand  the  scope  of  the  benchmarks,  (2)  integrate  the 
underlying  hardware  into  the  benchmarks,  (3)  develop  a 
driver  which  simulates  a  series  of  inputs  to  the  system, 

(4)  obtain  assembly  1  a n g u a g e / J 0 V  I AL  code  of  flight  control 
software  for  comparison  to  an  Ada  implementation. 

The  first  area  would  involve  incorporating  more  of  the 
functional  modules  of  the  AFTI/F-16  into  benchmarks  and 


running  them  on  I750A  processors.  This  could  include  ex¬ 
panding  the  current  benchmarks  or  developing  new,  separate 
benchmarks.  This  area  would  increase  the  accuracy  of  the 
benchmarks  by  making  them  more  representative  of  the  whole 
of  flight  control  software. 

The  second  area  would  involve  integrating  hardware 
into  the  benchmarks  to  provide  more  realistic  input  and 
output  of  data.  This  would  increase  the  realism  of  the 
overall  flight  control  system. 

The  third  area  would  involve  developing  a  driver  which 
feeds  data  to  the  benchmarks  and  causes  the  benchmarks  to 
take  a  number  of  paths  through  their  algorithms.  This  area 
would  increase  the  accuracy  of  the  benchmarks  by  including 
a  more  representative  sample  of  flight.  For  example,  a 
driver  could  include  take-off,  flight,  and  landing  conditions. 

The  fourth  area  would  involve  obtaining  some  actual 
flight  control  software  and  implementing  the  same  algorithms 
in  Ada,  running  both  programs,  and  evaluating  the  results. 

This  area  would  provide  a  sample  of  what  the  actual  costs 
are  of  implementing  flight  control  software  in  Ada  as  com¬ 
pared  another  language  (rather  than  among  Ada  implementations) 


Appendix  A:  Two  Styles  o  f  Coding  C  o  n  t  r o I  Laws 


Two  coding  styles  were  used  in  developing  the  control 
law  tests  for  flight  control  software.  The  two  methods  were 
different  in  the  way  in  which  variables  and  constants  were 
declared  and  used.  The  global  method  allows  all  modules  to 
use  all  variables  and  constants.  Figure  2  contains  a  sample 
of  the  global  coding  method.  As  indicated  by  the  scope  line 
along  the  left  side  of  Figure  2,  variables  A,  B,  C,  D  may  be 
used  throughout  the  MAIN  procedure.  Figure  3  contains  a 
sample  of  the  localized  coding  method.  The  scope  lines  in¬ 
dicate  that  variables  A  and  B  may  be  used  throughout  the 
MAIN  procedure,  while  variable  C  can  only  be  used  within 
Module  1,  and  variable  D  can  only  be  used  within  Module  2. 
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procedure  MA I N 

A:  integer  :=  0; 
B:  integer  :=  1; 

C:  integer  :=  2; 
D:  integer  :=  3; 
begin 

Scope  of  j 

A  ,  B  ,  C  ,  D 

Mo  d  u 1 e  1  : 

begin 

A  :  =  B  +  C  ; 

B  :  =  A  +  C,  ; 
end  Modu 1 e  1 ; 

1 

i 

j 

I 

j 

i _ 

Module  2  : 

begin 

A  :  =  B  +  D  ; 

D  :  =  A  +  B  ; 
end  Module  2; 
end  MAIN; 

Figure  2 

.  Global  Coding  Style 
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Scope  of 
A ,  B 


Scope  of 
C 


Scope  of 
D 


procedure  MA  I  N 
A:  integer  := 
B:  integer  := 
begin 

Modu 1 e_ 1  : 

declare 

C:  integer 
begin 

A  :  =  B  +  C  ; 

B  :  =  A  +  C  ; 
end  Modu 1 e_ 1 

Module_2  : 
declare 

D :  integer 
begin 

A  :  =  B  +  D  ; 

D  :  =  A  +  B  ; 
end  Mod u 1 e_2 
end  MAIN; 


Figure  3.  Local  Coding  Style 


Appendix  B:  Gain  Table  Interpolat  ion 


Figure  4  contains  a  part  of  the  gain  table  for  a  com¬ 
pensation  filter  frequency  from  the  AFTI/F-16.  The  table 
is  entered  with  two  known  values,  speed  (mach),  and  altitude 
static  air  pressure  to  sea  level  air  pressure  ratio  (Ps/Po). 
The  compensation  filter  frequency  value  is  determined  by  a 
double  interpolation  of  data  points  in  the  table.  The  dashed 
lines  in  Figure  3  graphically  portray  the  following  example. 
Enter  the  table  with  the  known  values  0.7  mach  and  0.5  Ps/Po. 
The  values  for  the  compensation  at  0.6  and  0.9  mach  at  0.297 
and  !.0  Ps/Po  are  determined  because  they  are  the  values 
between  which  the  known  values  fall.  Let  F(X,Y)  represent 


the  compensat 

ion 

at  X  mach  and  Y 

Ps/Po,  the  values  from 

the 

table  are: 

F  (  0 

.  6  ,  I  .  0  ) 

_ 

1364 

(4  ) 

F  (  0 

.9,  i .0) 

= 

1  680 

(5) 

F  (0 

.  6  ,  0.29  7  ) 

= 

1  1  54 

(6) 

F  (  0 

. 9 ,  0.297) 

1323 

(7) 

To  determine 

F  (0  . 

7,  0.5)  the  values 

of  F  (  0 . 7  ,  1.0)  and 

F ( 0 . 7 ,  0.297) 

are 

determined . 

F  (  0  . 

7  ,  1 

.0)  = 

1680  -  ((1680  -  1364)  * 

((0.9  -  0 . 

7) 

/  (0.9  -  0.6))) 

(8  ) 

F  (  0  . 

7,  1 

.0)  = 

1469.3 

(9) 

F  (  0  . 

7,  0 

.  2  9  7  ) 

=  132  3  -  (  (  ! 

323  -  1154)  * 

((0.9  - 

0  . 

7)  /  (0.9  -  0.6) ) ) 

(10) 

F  (  0  . 

7,  0 

.291) 

=  12  10.3 

(ID 

Next,  the  value  of  F(0.7,  0.5)  is  determined. 


F  (  0 . 7  , 

F  (  0  .  7  , 

1680 

1469.3 

Compensat ion 
Filter 
Frequency 
(Value  to  be 
determined  ) 

!  364 

132  3 

1242.8 

1210.3 

1  I  54 

0 


Figure  4  . 
(Not  to  s 


0.5)  =  1323  -  ((1323  -  1210.3)  * 

((1.0  -  0.5)  /  (1.0  -  0.297))) 

0.5)  =  1242.8 


0.297  0.5 


P  s  /  P  o 

Frequency  Compensation  Filter  Gain  Table 
ale)  (Henley  and  others,  19  8  4  : E  —  7  to  E-8) 


Appendix  C:  Sample  Test  R  e  s  u 1 t  s 


This  appendix  presents  the  results  obtained  when  the 
developed  benchmarks  were  run  on  two  1750A  processors  using 
two  Ada  compilers. 


Results  Evaluation  Criteria 


Variability  in  measurements  requires  that  a  statistical 
analysis  be  performed  to  insure  that  there  is  a  true  differ¬ 
ence  between  the  systems  being  compared.  Memory  space  used 
did  not  vary  from  one  compilation  to  the  next.  Execution 
speed  varied  only  in  the  two  control  law  benchmarks.  To 
compensate  for  this  variability  the  small  sample  t-test 
with  significance  level  o.  =  .05  was  used.  The  following 
equations  are  used  in  inferring  differences  between  two 
sample  means  (Mendenhall,  1975:222-227): 


pooled  estimator  s' 


(n  j  -  1  )  s  j  2  +  (n^  -  1  )  s  ^  ^ 


nl  +  °2  '  2 


test  statistic 


(y 1  "  y2 }  °0 


s  (  1  /  n  |  +  1  /  n  ^  ) 


confidence  interval  =  (y  -  y  „  )  t  s  (  I  /  n  +  l/n)  (3) 

( u  .  -  b  „  )  a  /  2 


Variables  are:  n  ^ ,  s  |  ,  y  |  -  number  of  samples,  variance. 


and  mean  value  under  condition  I,  n 


s 


.  y 


number  of 


samples,  variance,  and  mean  value  under  condition  2  .  The 
value  of  n  and  n  is  10  for  all  cases,  chosen  based  on 
initial  results  which  showed  small  variances  allowing  a 
small  number  of  samples  to  be  chosen  without  invalidating 
results.  Because  it  is  desired  to  determine  if  there  is  a 
difference  between  various  implementations,  the  null  hypo¬ 
thesis  is  |  =  p  and  the  alternate  hypothesis  is  p  f  • 

The  null  hypothesis  will  be  rejected  whenever  there  is  a 
statistically  significant  difference  between  the  compared 
implementations.  Finally,  the  rejection/non-rejection  of 
the  null  hypothesis  and  the  confidence  interval  have  a  95 
percent  assurance  that  they  are  correct  based  on  ot  =  .05  for 

each  individual  test. 


Control  Laws 

The  first  control  law  test  implemented  the  control  laws 
using  global  variables  for  all  data.  Results  are  shown  in 
Table  IV.  The  results  show  that  Processor  2  did  not  run 
the  benchmark  (indicated  by  an  asterisk  The  processor 

stopped  executing  after  several  hundred  instructions  but  no 
error  was  reported  and  none  could  be  found  after  a  lengthy 
search.  During  this  research  and  concurrent  research  efforts 
Processor  2  was  found  to  have  many  errors  (Pitarys,  1987). 
From  the  results  shown  in  Table  IV  Compiler  1  is  superior  to 
Compiler  2  in  both  execution  speed  and  code  size  generated 
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Table  IV.  Results  of  Control  Law  Test  With 
Global  Variables  and  Constants 

SPEED 

Compiler  1  Compiler  2 

Processor  I  5683.0  usees  9005.2  usees 

Processor  2  *  * 

CODE  S I ZE 

6550  bytes  9855  bytes 

*  benchmark  did  not  execute 

and  thus  is  judged  to  be  better  suited  for  control  law 

2  2 

computation  using  global  data.  With  Sj  =  2.0  and  s^  = 
0.17,  t  =  7142.9  and  t  ,  =  2.101.  Because  t  >  t  the 

hypothesis  that  the  means  are  equal  is  rejected,  and  the 
conclusion  is  that  there  is  a  difference  between  the  com- 
p i 1 er / run-time  systems.  There  is  95  percent  confidence  that 
the  means'  difference  is  3322.2  t  0.9  microseconds. 

The  second  test  implemented  the  same  control  laws  using 
local  variables  wherever  possible.  Results  are  shown  in 
Table  V.  Processor  2  again  did  not  run  the  benchmark  and 
reported  a  numeric  error.  Execution  was  halted  just  prior 
to  the  instruction  causing  the  numeric  error  and  values 
examined  to  determine  if  there  was  a  condition  which  would 
cause  the  error.  There  were  no  values  present  which  should 
have  caused  the  error  during  the  next  instruction.  The  next 


Table  V  . 


Results  of  Control  Law  Test  With 
Local  Variables  and  Constants 


SPEED 


Compiler  1 

Processor  I  6719.8  usees 

Processor  2  * 

*  benchmark  did  not  execute 


Compiler  2 
9900.7  usees 

Jz 


instruction  was  executed  and  a  numeric  error  raised  when  no 

error  should  have  been  raised.  Compiler  1  again  was  superior 

to  Compiler  2  in  speed.  Code  size  is  the  same  as  the  pre- 

2  2 

vious  test.  With  s  j  =  9.95  and  s^  =  1.12,  t  =  3026.7  and 

t  . „  =  2.101.  Because  t  >  t  _  the  hypothesis  that  the 

'u  2  Ci/  l 

means  are  equal  is  rejected,  and  the  conclusion  is  that  there 
is  a  difference  between  the  c omp  i  1 e r  /  RTS .  There  is  95  per¬ 
cent  confidence  that  the  means'  difference  is  3180.9  t  2.2 
microseconds  . 

This  test  also  provided  the  opportunity  to  determine 

whether  coding  style  effected  execution  speed.  For  Compiler 

1,  s,2  =  2.0  and  s  2  =  9.95,  t  =  950.0  and  t  =  2.101. 

I  2  a  /  2 

Because  t  t  the  hypothesis  that  the  means  are  equal  is 

Ci  /  2 

rejected,  and  the  conclusion  is  that  coding  style  does  affect 
execution  speed.  There  is  95  percent  confidence  that  the 
difference  is  1036.8  ±  2.3  microseconds.  For  Compiler  2 
s,2  =  0.17  and  s  2  =  1.12,  t  =  2501.0  and  t  =  2.101. 


rV^?rrVT 


Because  t  >  t  7  the  hypothesis  that  the  means  are  equal  is 
rejected,  and  the  conclusion  is  that  coding  style  does  affect 
execution  speed.  There  is  95  percent  confidence  that  the 
difference  is  895.0  t  0.7  microseconds. 

Gain  Table  Interpolat ion 

The  gain  table  access  and  interpolation  benchmark  per¬ 
forms  a  double  interpolation  between  data  points.  Results 
are  shown  in  Table  VI.  There  was  no  variance  in  the  results 
and  thus  no  compensation  for  statistical  variation  was 
needed.  The  results  show  Compiler  I  to  be  the  superior  in 
both  execution  speed  and  generated  code.  Based  on  the  re¬ 
sults  from  Compiler  1,  Processor  I  is  superior  in  speed  of 
execution.  This  result  was  expected  because  Processor  1  is 
rated  at  roughly  twice  the  speed  of  Processor  2. 


Table  VI.  Gain  Table  Interpolation 

SPEED 

Compiler  1  Compiler  2 

Processor  I  160  usees  213  usees 

Processor  2  310  usees  * 

CODE  S I ZE 

140  bytes  186  bytes 

*  benchmark  did  not  execute 


Red  ujn  d  a  n  c  y  N  a  nagement 

The  redundancy  management  benchmark  implements  the 
leading-edge  flap  (LEF)  monitor  portion  of  the  AFTI/F-16 
redundancy  management  function.  This  test  was  run  in  two 
versions  to  provide  a  more  robust  evaluation:  the  first 
started  with  no  monitored  systems  failed  and  none  detected 
during  execution;  the  second  had  some  initial  system  fail¬ 
ures  and  detected  additional  failures  during  execution. 
Tables  VII  and  VIII  show  the  results.  There  was  no  variance 
during  the  test  runs  so  no  statistical  compensation  was 
required.  For  both  versions  of  the  test  Compiler  )  was 
superior  to  Compiler  2  in  both  generated  code  and  execution 
speed.  As  noted  in  the  previous  section  Processor  I  is 
faster  than  Processor  2,  and  the  results  bear  this  out. 

Table  VII.  LEF  Monitor  With  No  Failures  Detected 
During  Execution 

SPEED 

Compiler  1  Compiler  2 

Processor!  381  usees  ^23  usees 

Processor  2  726  usees  * 

CODE  SIZE 

713  bytes  765  bytes 


*  benchmark  did  not  execute 


Table  VIII. 


Processor  1 
Processor  2 


LEF  Monitor  With  Failures  Detected 
During  Execution 


SPEED 

Compiler  1  Compiler  2 

508  usees  544  usees 

990  usees  * 


*  benchmark  did  not  execute 


Ada  Informat 
198  7  . 


Clearinghouse.  Ada  Newsletter ,  5 :  April, 


Barfield,  Finley.  Flight  Control  System  Engineer.  Personal 
Interviews.  AFWAL/FIG1,  Wright-Pat terson  AFB  OH,  March 
October  1987. 

Bassman,  Mitchell  J.  and  others.  "An  Approach  for  Evaluat¬ 
ing  the  Performance  Efficiency  of  Ada  Compilers,"  Ada 
L  e  t  t  e  r  s  ,  :  September  -  October  1985. 

Bennell,  Nicholas  and  others.  Benchmark ing :  Compu  ter  Evalua- 
t i o  n  and  Measurement  .  Washington,  D.C.:  Hemisphere  Pub¬ 
lishing  Corporation,  1975. 

Booch,  Grady.  Software  Engineering  With  Ada .  Menlo  Park, 
California:  The  Ben  j  am  i  n  /  Cumin  i  ngs  Publishing  Company, 

I  n  c  .  ,  1  9  8  3  . 

Clapp,  Russell  and  others.  "Toward  Real-Time  Performance 

Benchmarks  for  Ada,"  Comm unicat  ions  o  f  the  ACM ,  2  9  :  7  60- 


778  (August,  1986). 


Craine,  Cape  David.  Ada  Comp  i  1 e  r  Eva  1 u a  t  i  o  n  Techniques  for 
Real-time  Avionics  AppI  icat  ions.  MS  Thesis,  AF1T/GCS/ 
MA/86D-3.  School  of  Engineering,  Air  Force  Institute 
of  Technology  ( A  U )  ,  Wright-Patterson  AFB  OH,  December 
19  8  6. 


Department  of  Defense.  C  o 
DOD  Directive  3405.1. 
Office,  2  April  1987. 


iuter  P  r  o  g  r  amm  ing  Language  Pol  i c ; 
Washington:  Government  Printing 


Department  of  Defense.  Mil  itary  Standard  :  Ada  P  r  o  g  r  amm  ing 

Language  .  ANSI/MIL-STD-1815A.  Washington:  Department  of 
Defense,  22  January  1983. 

Department  of  Defense.  Military  Standard  :  Sixteen-Bit  Comp- 

uter  Instruction  Set  Archi  tecture .  MIL-STD-1750A.  Wash¬ 
ington:  U.S.  Government  Printing  Office,  21  May  1982. 


DeThomas,  Tony. 
Interviews  . 
October  1987 


Flight  Control  Sysstems  Engineer.  Personal 
AFWAL/FIGX,  Wright-Patterson  AFB  OH,  July  - 


Henley,  G.  D.  and  others.  AFTI/F  -  16  Development  and  Integra¬ 
tion  Program  ;  D  F  C  S  Phase  Final  Technical  Report  ,  Volume 
3,  Part  3,  Contract  F33615-78-C-3022.  Fort  Worth,  Texas: 
General  Dynamics,  December  1984. 

Hicks,  Brian.  Computer  Engineer,  F  —  1 6  SPO.  Personal  Inter¬ 
views.  ASD/YPES,  Wright-Patterson  AFB  OH,  October  1987. 

Hook,  Audrey  and  others.  User  1  s  Manual  for  the  Prototype  Ada 
Compiler  Evaluat  ion  Capability  ( A  C  E  C  )  .  Alexandria, 
Virginia:  Institute  for  Defense  Analyses,  October  1983. 

Johnston,  Ann.  Flight  Controls  Engineer.  Telephone  Inter¬ 
views.  General  Dynamics,  Fort  Worth,  Texas,  August  - 
October  1987. 

Joslin,  L  t  Paul.  Flight  Control  Software  Manager.  Personal 
Interviews.  AFWAL/FIGI,  Wright-Patterson  AFB  OH,  March  - 
August  1987. 

Joyce,  Cap  t  Daniel  0.  Val  idat  ing  and  Eval uat ing  Ada's 

Representat  ion  Clauses  o  n  MIL-STD-  1  7  5  0  A  Architecture. 

MS  Thesis,  AFIT/GCS/MA/87D-6.  School  of  Engineering, 

Air  Force  Institute  of  Technology  (AU),  Wright-Patterson 
AFB  OH,  December  1987. 

Lahn,  T.  G.  and  others.  S  o  me  Vie  uos  on  the  Use  o  f  Ada  for 
Digital  FI  i  gh  t  C  o  n  t  r  o  1  Systems .  Unpublished  report. 
Honeywell  Military  Avionics  Division,  Minneapolis,  Min¬ 
nesota,  undated. 

Landy,  R.  J.  and  others.  Ada  B^a  sed  Integrated  Control  System 
J__f  (Draft ) .  St.  Louis,  Missouri:  McDonnell  Douglas  Corp. 
Dec  embe  r  19  8  6. 

Lewantowicz,  Lt  Col  Zdzislaw.  Instructor  and  Deputy  Head 

Department  of  Electrical  and  Computer  Engineering.  Per¬ 
sonal  Interview.  AFIT/ENG,  Wright-Patterson  AFB  OH, 
October  1987. 

Mellby,  John.  Control  Systems  Engineer.  Telephone  Interview 
Texas  Instruments,  Houston,  Texas,  16  July  1987. 

Mendenhall,  William.  Introduction  to  Probabili  ty  and 

Statistics  (Fourth  Edition).  North  Scltuate,  Massa¬ 
chusetts:  Duxbury  Press,  1975. 


Pitarys,  Lt  Marc.  Avionics  System  Engineer.  Personal  Inter¬ 
views.  AFWAL/AAAT,  Wright-Patterson  AFB  OH,  March  - 
Au  gu  s  t  19  8  7. 


R  a  m  a  g  e  ,  James  K.  and  others.  "  AFT1/F-I6  Digital  Flight  Contr 
System  Development  Status,"  Presented  at  the  Fourth  A I /.  A/ 
IEEE  Digital  Avionics  System  Conference.  November  17- 
19,  1981. 

Startzman,  Ty.  Control  Systems  Engineer.  Telephone 

Interviews.  Boeing  Aerospace,  Wichita,  Kansas,  July  - 
August  1987. 

Squire,  Jon.  Chairman,  PIWG  of  the  ACM.  Telephone  Interview 
Westinghouse  Defense  and  Electronics  Center,  Baltimore, 
Maryland,  29  June  1987. 

- .  PIWG  Benchmark  Programs  contained  in  the  directory 

•  INFO-ADA. PIWG >  on  ADA20.1SI.EDU  on  the  ARPANET.  Balti¬ 
more,  Maryland:  Westinghouse  Defense  and  Electronics 
Center,  August  1986. 

Toolean,  Bill.  Flight  Systems  Engineer.  Telephone  Inter¬ 
views.  Grumman  Aircraft,  Long  Island,  New  York,  July  - 
September  1987. 

University  of  Colorado  at  Colorado  Springs.  I FCC  Software  : 

Ad  a  Language ,  Contract  F  3  3 6  1  5  -  8 9 - K- 3 6 0 2  .  Colorado 
Springs,  Colorado:  University  of  Colorado  at  Colorado 
Springs,  January  1986. 

Weicker,  Reinhold  P.  "Dhrystone:  A  Synthetic  Systems 

Programming  Benchmark,"  Commun  ications  o  f  the  ACM ,  2  7  : 

1013-1027  (October,  1984).  .  . ~ 

Westermeier,  T.  F.  and  H.  E.  Hansen.  "The  Use  of  Ada  in 

Digital  Flight  Control  Systems,"  A I AA  Journal  ,  2_2  :  5  9  7  — 

603  (August,  1985). 

Witt ,  Capt  Donald  J.  Using  Ada  i n  the  Real-Time  Av ionics 

E  n  v i r  o  nme  n  t  :  Issues  and  Answers  .  MS  Thesis,  AFIT/GCS/ 
MA/85D-6.  School  of  Engineering,  Air  Force  Institute 
of  Technology  ( A  U )  ,  Wright-Patterson  AFB  OH,  December 
19  8  5. 

Yousey,  W .  J.  and  others.  AFTI  /  F-  16  Development  and  Integra  - 
t  i  o  n  Prog  ram  ;  D_F  C_S  Phase  Final  Technical  Report  ,  Volume  3 
Part  2,  Contract  F336I5-78-C-3022.  Fort  Worth,  Texas: 
General  Dynamics,  December  1984. 


John  D.  K lemons  was  born  on  15  September  1956  in 


I  v :  s  v  i  i  i  e  ,  Ohio.  He  graduated  from  Louisville  High  School 
in  i  H  7  .  He  then  attended  Ohio  University  from  1974  to 
w  r  t  r  e  he  received  a  Bachelor  of  Science  Degree  in 
i  ::y  >  r  Science.  While  at  Ohio  University,  he  enrolled 

in  Arne  K  0  T  l  and  was  commissioned  a  second  lieutenant  of 


Field  Artillery  on  10  June  1978.  After  attending  basic 


a  r  :  :  .  .  e  r  v  sen. 


I  he  served  in  Germany  for  three  years  in 


v  a  r  ions  artillery  positions.  He  returned  to  the  United 
States,  attended  advanced  artillery  school,  served  in 
various  positons  concluding  with  a  Battery  command  at 
Fort  Polk,  Louisiana  until  July  1986.  He  then  reported 
to  the  Air  Force  Institute  of  Technology  at  Wright- 
Patterson  AFB,  Ohio. 

Permanent  address:  1118  East  Broad  Street 

Louisville,  Ohio  4464i 


SECURITY  CLASSIFICATION  Of  THIS  PAGE 


REPORT  DOCUMENTATION  PAGE 


lb  RESTRICTIVE  MARKINGS 


Form  Approved 
OMB  H o  0704-0188 


REPORT  SECURITY  CLASSIFICATION 

UNCLASSIFIED 


2a  SECURITY  CLASSIFICATION  AUTHORITY 


2b  DECLASSIFICATION- DOWNGRADING  SCHEDULE 


4  PERFORMING  ORGANIZATION  REPORT  NUMBER(S) 

AFIT/CCS/ENC/87D-3 


3  DISTRIBUTION  /AVAILABILITY  OF  REPORT 

Approved  for  public  release; 
distribution  unlimited. 


5  MONITORING  ORGANIZATION  REPORT  NuMBER(S) 


6a  NAME  OF  PERFORMING  ORGANIZATION 

School  of  Engineering 

6b  OFFICE  SYMBOL 
(If  applicable) 
AFIT/ENG 

7a.  NAME  OF  MONITORING  ORGANIZATION 

6c  ADDRESS  (City,  State,  and  ZIP  Code) 

Air  Force  Institute  of  Technology 
Wright-Patterson  AFB,  Ohio  45433-6583 

7b  ADDRESS  (C/ty,  State,  and  ZIP  Code) 

8a  NAME  OF  FUNDING /SPONSORING 
ORGANIZATION 

Sb  OFFICE  SYMBOL 
(If  applicable) 

9  PROCUREMENT  INSTRUMENT  IDENTIFICATION  NUMBER 

8c.  ADDRESS  (City,  State,  and  ZIP  Code) 


1 1  TITLE  (Include  Security  Classification) 

See  Box  19 


■J  PERSONAL  AUTHOR(S) 

0  ohn  D.  Klemens,  B.S.,  CPT,  USA 


13a.  TYPE  OF  REPORT  1  3b  TIME  COVERED 

MS  Thesis  from _ to. 


16  supplementary  notation 


10  SOURCE  OF  FUNDING  NUMBERS 


PROGRAM 
ELEMENT  NO 


PROJECT 

TASK 

NO 

NO 

WORK  UNIT 
ACCESSION  NO 


14  DATE  OF  REPORT  (Year,  Month,  Day)  15  PAGE  COUNT 

198  7  Decembe  r  74 


17  COSATl  CODES 


FIELD  GROUP  SUB-GROUP 


18  SUBJECT  TERMS  ( Continue  on  reverse  if  necessary  and  identify  by  block  number) 
Language-Programming  Languages-Ada 
Flight  Control  Systems-Control  Systems 


19  ABSTRACT  ( Continue  on  reverse  if  necessary  and  identify  by  block  number) 

Title:  Examination  of  the  Effects  of  Using  Ada  in  Flight  Control  Software 

Thesis  Chairman:  Richard  R.  Gross,  Lt  Col,  USAF 

Assistant  Dean,  School  of  Engineering 


0  DISTRIBUTION  AVAILA8ILITY  of  ABSTRACT  21  ABSTRACT  SECURITY  CLASSIFICATION 

□  UNClASSlFiED'UNLlMiTED  E  SAME  AS  RPT  □  DTIC  USERS  UNCLASSIFIED 


22a  NAME  OF  RESPONSIBLE  individual  22 b  TELEPHONE  (Include  Area  Code)  22c  OFFICE  SYMBOL 

Richard  R.  Gross,  Lt  Col,  USAF  (513)  255-4372  AFIT/ENA 


DO  Form  1473,  JUN  86  Previous  editions  are  obsolete  SECURITY  classification  Of  this  page 

UNCLASSIFIED 


s- 


y. 


UNCLASSIFIED 


Abstract 

This  research  characterizes  flight  control  software  in 
terms  of  the  Ada  (TM)  constructs  used  and  of  the  performance 
characteristics  that  determine  the  suitability  of  a  partic¬ 
ular  compiler/processor  system  for  flight  control  software. 

A  new  set  of  three  flight  control  software  benchmarks  based 
on  this  characterization  was  evaluated  on  two  M I L- STD-  )  7  50A 
processors  using  two  Ada  compilers.  Results  show  that  com¬ 
piler/processor  combinations  can  be  compared  for  their  abil¬ 
ity  to  implement  flight  control  software  in  execution  speed 
and  memory  size  required.  The  benchmarks  provide  time  and 
space  requirements  for  a  typical  sample  of  flight  control 
software. 


UNCLASSIFIED 


